HTTPS Redirect on IIS (web.config)

Unlike cPanel or Plesk, IIS (Windows hosting) doesn't have a simple admin checkbox for forcing HTTPS — the redirect is configured through the URL Rewrite module and a rule added to web.config.

The rule

<rule name="HTTP to HTTPS redirect" stopProcessing="true">
  <match url="(.*)" />
  <conditions>
    <add input="{HTTPS}" pattern="off" ignoreCase="true" />
  </conditions>
  <action type="Redirect" url="https://{HTTP_HOST}/{R:1}"
    redirectType="Permanent" />
</rule>

This goes inside the <system.webServer><rewrite><rules> section of your site's web.config. The URL Rewrite module needs to be installed on the IIS server first — it's a free, separate download from Microsoft if it isn't already present.

Alternative: IIS Manager's redirect feature

IIS Manager also has a built-in HTTP Redirect feature under the site's settings that can achieve the same result through the GUI rather than editing XML, though it offers less granular control than a URL Rewrite rule.

Why the URL Rewrite module needs separate installation on IIS

Unlike Apache and Nginx, where rewrite capability is often built in or bundled by default, IIS requires the URL Rewrite module as a separate, free download from Microsoft before the web.config rule shown in our guide will function at all — attempting to add the rule without first installing the module produces a configuration error rather than a working redirect.

What the IIS Manager GUI alternative to editing web.config looks like

IIS Manager includes a built-in HTTP Redirect feature accessible through the GUI, under the site's settings, that can achieve a similar result without immediately editing XML — it offers less granular control than a hand-written URL Rewrite rule, but it's a reasonable, simpler option for administrators less comfortable editing configuration files directly.

What a common IIS-specific error looks like when the rewrite rule is misconfigured

A malformed URL Rewrite rule in web.config typically produces an HTTP 500.19 configuration error rather than a working redirect — checking the exact XML syntax against the working example in our guide, particularly matching tags and attributes precisely, resolves the large majority of these configuration errors.

What Application Request Routing adds if you're also using IIS as a reverse proxy

If IIS is also functioning as a reverse proxy via the Application Request Routing module, the same forwarded-header considerations covered for other reverse proxy setups apply — backend applications behind IIS-as-proxy need to trust IIS's forwarded protocol information rather than checking their own connection state directly.

How to apply the same rewrite rule across multiple sites in one IIS installation

Rather than duplicating the redirect rule in every individual site's web.config, adding it to the server-level applicationHost.config applies it consistently across every site on the server — a more maintainable approach when managing several sites that all need identical redirect behavior.

Why testing the rule in IIS Manager's rule testing feature saves debugging time

IIS Manager's URL Rewrite interface includes a built-in rule tester that lets you enter a sample URL and see exactly how your rule would process it, without needing to in practice deploy the change and test against a live request — a faster iteration cycle while getting the rule's syntax correct.

What Windows Server version considerations apply to this configuration

The URL Rewrite module and web.config approach covered in this guide work consistently across supported Windows Server versions running IIS 7 and later — very old, unsupported Windows Server versions may have compatibility limitations worth checking against Microsoft's current IIS documentation.

How this guide's approach differs for an ASP.NET application versus a static site on IIS

The web.config redirect rule works identically regardless of whether IIS is serving a static site or an ASP.NET application, since the rule operates at the IIS request-handling level before reaching any application code — no ASP.NET-specific configuration is needed beyond the standard rule.