Redirect to https in the web.config

There’s a special kind of irritation that only web developers know: you hit F5 in Visual Studio expecting a friendly little http://localhost:12345, and instead your browser lunges straight into HTTPS like it’s late for a security audit. Suddenly you’re staring at a certificate warning, your cookies don’t match, and your dev environment feels like it’s cosplaying as production.

The culprit is almost always the same—a well-intentioned rewrite rule that does exactly what you told it to do, not what you meant for it to do.

If you’ve ever wondered why your local site keeps force-redirecting to HTTPS even though you never asked for it, this post walks through the exact reason, the fix, and the cleanest way to keep production locked down without making development annoying.

Related Articles

... and you 'll find more on the NET Development Menu

When you add an HTTP-to-HTTPS redirect rule in web.config, IIS doesn’t care whether you’re running on a production server or a dusty little localhost port. It just sees a rule, evaluates the conditions, and executes the redirect. That’s its entire job.

Here’s the rule most developers add to secure their production site:

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

At first glance, it looks simple:

If HTTPS is off → redirect to HTTPS.

If the host is not localhost → redirect to HTTPS.

That second condition is the magic. Without it, your dev environment gets swept up in the redirect and you end up debugging through a certificate warning like it’s 2009.

Why this rule matters

Production should always enforce HTTPS. Search engines expect it, browsers prefer it, and your users deserve it. But development is different. Localhost doesn’t need a certificate, and Visual Studio’s self-signed certs are more annoying than helpful when you’re just trying to test a layout or debug a controller.

By adding:

 

<add input="{HTTP_HOST}" pattern="localhost" negate="true" />
…you’re telling IIS:

“Redirect everything to HTTPS—unless I’m on localhost.

Localhost gets a free pass.”

This keeps production secure and development friction-free.

Here's the production code:

 

<system.webServer>
  <rewrite>
    <rules>
      <rule name="HTTP to HTTPS" stopProcessing="true">
        <match url="(.*)" />
        <conditions>
          <add input="{HTTPS}" pattern="off" ignoreCase="true" />
          <add input="{HTTP_HOST}" pattern="localhost" negate="true" />
        </conditions>
        <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
      </rule>
    </rules>
  </rewrite>
  <handlers>
    <remove name="Telerik_Web_UI_WebResource_axd"/>
    <add name="Telerik_Web_UI_WebResource_axd" path="Telerik.Web.UI.WebResource.axd" type="Telerik.Web.UI.WebResource" verb="*" preCondition="integratedMode"/>
  </handlers>
</system.webServer>

 

RealWorldCode gives developers practical, real‑world solutions with clean, working code — no fluff, no theory, just answers.
Links
Home
Knowledge Areas
Sitemap
Contact
Et cetera
Privacy Policy
Terms and Conditions
Cookie Preferences