IIS

What Is Microsoft IIS?

Microsoft Internet Information Services (IIS) is the web server that ships with the Windows Server operating system. It is Microsoft's flagship platform for hosting websites, web applications, and APIs on Windows, and it has been a core part of the Windows ecosystem since the mid-1990s. If a site runs on Windows in any serious capacity, IIS is almost always the server answering HTTP requests at the front.

Here is the single most useful fact to anchor everything else: IIS is the Windows-native counterpart to Nginx, Apache, and LiteSpeed, but it is uniquely tied to the Microsoft stack. It is the natural home for ASP.NET, ASP.NET Core, classic ASP, and applications that depend on Windows services, Active Directory authentication, or the .NET runtime. Where you find IIS, you are usually looking at a Microsoft-centric organization or a product built on Microsoft technologies. According to W3Techs' long-running web-server survey, IIS sits among the most widely deployed servers on the public web, though it trails the open-source leaders Nginx and Apache in raw share; treat that as a well-established qualitative ranking rather than a precise number, since the figures move month to month.

IIS is a mature, full-featured server. It handles static files, dynamic application hosting, TLS termination, URL rewriting, compression, caching, authentication, logging, and process management for application pools. Because it is bundled with Windows Server rather than sold separately, it is effectively "free" for anyone already licensing the operating system, which is a large part of why it remains entrenched in enterprises, government, healthcare, finance, and any environment standardized on Microsoft infrastructure.

How Microsoft IIS Works

IIS is built around a modular, request-pipeline architecture. When a request arrives, it passes through a kernel-mode listener and then a configurable series of modules before a handler generates the response. Understanding the major pieces explains both its behavior and its fingerprints.

• HTTP.sys. At the lowest level, a kernel-mode driver called HTTP.sys receives incoming connections, performs initial parsing, manages connection queuing, and provides response caching. Because it lives in the Windows kernel, it is fast and also responsible for some of the distinctive error responses you may see.
• Worker processes and application pools. IIS isolates applications into application pools, each backed by one or more worker processes (w3wp.exe). A pool can be recycled, throttled, or given its own identity and resource limits, so one misbehaving application does not take down others on the same server.
• Modules. The request pipeline is composed of native and managed modules that handle authentication, static file serving, compression, caching, URL rewriting, logging, and more. Administrators enable or disable modules to shape behavior.
• Handlers. A handler is the component that ultimately produces a response for a given request type, for example the ASP.NET handler for .aspx pages or a static-file handler for images and downloads.

Configuration is hierarchical and XML-based. The server-wide settings live in applicationHost.config, while per-application and per-directory settings live in web.config files that can be nested down the directory tree. This web.config model is conceptually similar to Apache's .htaccess: it lets a developer override settings (rewrite rules, authentication, custom error pages, MIME types) for a specific folder without touching server-wide configuration. Management is typically done through the IIS Manager graphical console, the appcmd command-line tool, or PowerShell.

The defining relationship is between IIS and the .NET runtime. For classic ASP.NET, IIS hosts the .NET Common Language Runtime in-process and routes requests through the ASP.NET pipeline. For modern ASP.NET Core, IIS usually acts as a reverse proxy in front of the cross-platform Kestrel server using the ASP.NET Core Module, forwarding requests to the application process. That second arrangement matters for detection, because the public-facing server can still be IIS even when the application itself is a portable .NET Core app.

How to Tell if a Website Uses Microsoft IIS

IIS tends to announce itself clearly through HTTP response headers, and the surrounding Microsoft stack leaves a rich trail of corroborating signals. As always, the responding server may be an edge layer rather than the true origin, so read every signal as "what answered at this hop."

The Server response header

The most direct tell is the HTTP Server response header. An IIS endpoint typically returns a value like:

Server: Microsoft-IIS/10.0

The version number maps to the Windows Server release (for example, IIS 10.0 corresponds to Windows Server 2016 and later, IIS 8.5 to Windows Server 2012 R2, and so on). Security-conscious administrators sometimes remove or rewrite this header, but in practice the Microsoft-IIS string is one of the most reliable fingerprints on the web.

You can read the header with command-line tools or the browser:

• curl: Run curl -I https://example.com to issue a HEAD request and print only the response headers, then scan for Server: Microsoft-IIS.
• Browser DevTools: Open DevTools, switch to the Network tab, reload the page, click the top (document) request, and read the Response Headers section.
• Wappalyzer: This browser extension and similar tools fingerprint the Server header automatically and will label the site as IIS, often alongside ASP.NET and the .NET version.

ASP.NET and .NET corroborating headers

IIS rarely travels alone. When a site is built on the Microsoft web stack, several additional headers commonly appear together and reinforce the diagnosis:

• X-Powered-By: ASP.NET advertises the ASP.NET framework sitting on top of IIS.
• X-AspNet-Version: 4.0.30319 reveals the specific .NET Framework version handling requests.
• X-AspNetMvc-Version: 5.2 indicates the application uses ASP.NET MVC and names its version.

Seeing Microsoft-IIS together with any of these is about as conclusive as fingerprinting gets. Modern, hardened deployments increasingly strip these X- headers for security, so their absence does not rule IIS out, but their presence is a strong positive signal.

URL patterns, cookies, and error pages

The shape of the application leaves fingerprints beyond headers:

• .aspx URLs. Page extensions such as .aspx, .ashx, .asmx, or .asp in links and routes are classic indicators of an ASP.NET or classic ASP application hosted on IIS.
• Session cookies. Classic ASP applications set an ASPSESSIONID cookie, while ASP.NET applications typically set ASP.NET_SessionId. A __RequestVerificationToken or .ASPXAUTH cookie is similarly telling.
• Default and error pages. A default IIS welcome page or a distinctive ASP.NET "Yellow Screen of Death" exception page (yellow and white with a stack trace) strongly implies IIS. HTTP.sys also emits a characteristic minimalist error page for certain low-level errors.

IP, reverse DNS, and asset domains

Network-level checks add another layer. Use dig or nslookup to resolve the domain, then perform a reverse-DNS lookup on the resulting address. Because IIS runs on Windows Server, sites are frequently hosted on Microsoft Azure or in Windows-centric data centers; an IP that reverse-resolves into Azure ranges, combined with IIS headers, paints a coherent picture. Be aware, though, that IIS itself is operating-system software, not a hosting provider, so the IP only tells you where it is running, not that it is IIS.

The crucial caveat: CDNs and reverse proxies mask the origin

This is the most important detection nuance. If a site sits behind a content delivery network such as Cloudflare, Akamai, Azure Front Door, or Fastly, the Server header you receive describes the CDN edge, not the IIS origin. You may see Server: cloudflare even though the origin is pure IIS. The reverse also happens: a front-end Nginx or hardware load balancer may terminate TLS and forward to IIS behind it, so the public header says nginx while IIS does the real work. Because of this masking, header inspection alone can mislead. Corroborate with ASP.NET headers, .aspx URLs, ASP.NET cookies, and error-page fingerprints, and where possible use a server-side analysis that weighs many signals at once rather than trusting a single header.

Key Features

IIS is a comprehensive server platform. Its most important capabilities include:

• Deep .NET integration. First-class hosting for ASP.NET, ASP.NET Core, and classic ASP, with the CLR managed in-process for the classic framework and reverse-proxied to Kestrel for .NET Core.
• Application pools and process isolation. Independent worker processes with configurable identities, recycling schedules, and resource limits keep applications isolated and resilient.
• Windows authentication. Native integration with Active Directory, Kerberos, and NTLM makes single sign-on for intranet and enterprise applications straightforward.
• URL Rewrite module. A powerful rules engine for redirects, canonicalization, and friendly URLs, comparable to Apache's mod_rewrite.
• Centralized certificate and TLS management. TLS termination with support for modern protocols, managed through the IIS console or Windows certificate store.
• Static and dynamic compression and caching. Built-in output caching and Gzip/Brotli compression reduce bandwidth and latency.
• Graphical and scriptable administration. The IIS Manager console, appcmd, and PowerShell cmdlets give administrators both point-and-click and automation-friendly control.
• Detailed logging and diagnostics. W3C-format request logs, Failed Request Tracing, and tight integration with Windows event logging and performance counters.

Pros and Cons

IIS is a strong choice in the right environment and a poor fit outside it. The trade-offs are clear.

Pros

• Bundled with Windows Server, so no separate purchase or license is required.
• Unmatched integration with the .NET ecosystem and Microsoft tooling such as Visual Studio.
• Native Windows authentication and Active Directory single sign-on.
• Mature graphical administration that lowers the barrier for Windows administrators.
• Robust process isolation and recycling for reliability.
• Backed by Microsoft with long-term support and predictable patch cadence.

Cons

• Tied to Windows Server, which carries operating-system licensing costs and a heavier resource footprint than Linux.
• Less common in cloud-native, container-first, and open-source-leaning stacks, where Nginx dominates.
• Historically a larger attack surface, demanding disciplined patching and hardening.
• Configuration through nested XML web.config files can become unwieldy at scale.
• Smaller community and fewer third-party tutorials than the open-source leaders.

Microsoft IIS vs Alternatives

IIS is most often compared with Nginx, the Apache HTTP Server, and LiteSpeed. The table summarizes the trade-offs.

Feature	Microsoft IIS	Nginx	Apache HTTP Server	LiteSpeed
Primary platform	Windows Server	Linux/Unix (cross-platform)	Linux/Unix (cross-platform)	Linux/Unix
License/cost	Bundled with Windows	Open source (free)	Open source (free)	Commercial (free OpenLiteSpeed)
Best-fit stack	ASP.NET / .NET	Reverse proxy, any backend	PHP, shared hosting	PHP, WordPress, cPanel
Per-directory config	web.config	No (centralized)	.htaccess	.htaccess compatible
Native auth	Windows / Active Directory	Module-based	Module-based	Module-based
Common Server header	Microsoft-IIS/x.y	nginx	Apache	LiteSpeed

If a site is leaving the Microsoft stack or running cross-platform .NET behind a Linux edge, Nginx is the most common alternative front-end; for Windows-native applications and Active Directory integration, IIS remains the natural choice.

Use Cases

• Enterprise ASP.NET applications. Internal line-of-business apps, portals, and APIs built on the .NET Framework or ASP.NET Core, especially where Windows authentication is required.
• Intranet and Active Directory single sign-on. Sites that authenticate employees seamlessly against corporate identity infrastructure.
• Legacy classic ASP and .NET Framework workloads. Long-lived applications that depend on Windows-only components and cannot easily migrate.
• Hosting on Windows-based cloud and on-premises servers. Workloads standardized on Windows Server, frequently running on Microsoft Azure.
• Reverse proxy for ASP.NET Core. Acting as the public front end while Kestrel runs the portable .NET application behind it.
• Technology research and lead generation. Identifying IIS (and the ASP.NET stack around it) signals a Microsoft-centric organization, which is valuable for partners, competitors, and B2B prospecting. Learn more in our guides on how to find out what server software a website runs and how to find out what programming language a website uses.

Frequently Asked Questions

How can I tell if a website is running on IIS?

The fastest method is to inspect the HTTP Server response header. Run curl -I https://example.com or open your browser's DevTools Network tab, click the document request, and look at the response headers. A value like Server: Microsoft-IIS/10.0 is a direct indicator. Corroborating signals include X-Powered-By: ASP.NET, X-AspNet-Version, .aspx page extensions in the URLs, and an ASP.NET_SessionId or ASPSESSIONID cookie. A browser fingerprinting extension such as Wappalyzer can surface these automatically. For a fuller breakdown, see our guide on how to read a website's HTTP headers.

What is the difference between IIS and ASP.NET?

They operate at different layers and are easy to confuse because they so often appear together. IIS is the web server: the software that listens for HTTP requests and returns responses on Windows. ASP.NET is the application framework that developers use to build the dynamic logic of the site, which IIS then hosts and serves. In short, IIS is the server, and ASP.NET is the application running on it. You can run static sites on IIS with no ASP.NET at all, and modern ASP.NET Core apps can even run on Linux without IIS, but the classic pairing of IIS plus ASP.NET on Windows remains extremely common.

Does the X-Powered-By header always appear on IIS sites?

No. The X-Powered-By: ASP.NET header is added by default on many ASP.NET deployments, but it is purely informational and is frequently removed for security reasons to avoid advertising the technology stack. Its absence does not mean a site is not running IIS or ASP.NET. Rely on the combination of the Server header, URL patterns, cookies, and error-page fingerprints rather than any single header, and remember that a CDN or proxy can strip or rewrite these values entirely.

Can IIS run behind a CDN, and how does that affect detection?

Yes, and it is common. When IIS sits behind a CDN such as Cloudflare, Akamai, or Azure Front Door, the public Server header reflects the CDN edge rather than the IIS origin, so you might see Server: cloudflare even though the origin is IIS. Likewise, a front-end load balancer or Nginx proxy can terminate connections and hide IIS. Because of this masking, header inspection alone is unreliable. The more durable signals are application-level: .aspx extensions, ASP.NET cookies, and the distinctive ASP.NET exception page, ideally confirmed with a server-side analysis that weighs many signals together.

Is IIS free to use?

IIS is included with the Windows Server operating system at no additional charge, so there is no separate license fee for the web server itself. However, you do need a licensed copy of Windows Server (or a Windows-based cloud instance) to run it, which carries its own cost. This contrasts with Nginx and Apache, which are fully open source and run free on Linux. The practical takeaway is that IIS is cost-effective for organizations already invested in Windows licensing and comparatively expensive for those that would otherwise run on Linux.

What versions of IIS are current, and how do they map to Windows?

IIS versions track the Windows Server release they ship with. IIS 10.0 is the version found on Windows Server 2016, 2019, and 2022, as well as Windows 10 and 11. IIS 8.5 corresponds to Windows Server 2012 R2, IIS 8.0 to Windows Server 2012, and IIS 7.5 to Windows Server 2008 R2. Because the version in the Server header reveals the underlying Windows generation, an old IIS version is also a hint that the operating system may be dated and potentially missing security updates, which is useful context when you are profiling a site.

Need to confirm whether a site truly runs IIS behind its CDN and map the full Windows and ASP.NET stack around it? Run a server-side analysis with StackOptic.