Force Internet Explorer to use standards mode: X-UA-Compatible HTTP header

Hello World,

We have this fantastic application of ours that is trying to render HTML 5 graphs using Google’s chart API. Before I describe the issue we faced with IE and its resolution, let me touch a few aspects of why we chose Google Charts as the library of choice.

Choosing a Charting Library

This application I’m talking about uses the ASP.NET Web API to expose REST URIs that can accept request parameters and send back JSON formatted data as response. We needed a library that could:

  1. Accept data as JSON objects or JSON arrays
  2. Had the chart types we needed to show (Bar, Line series, Area)
  3. Did not have a steep learning curve – one is always short of time!
  4. Was open source so that we could tweak it to suit our specific scenarios
  5. Had a decent set of defaults – i.e. did not required too much configuration to get up and running

As you look at the documentation for Google Charts, you’ll notice that it meets all of the above (and more). I’ll reserve the details of the fun we had while developing with this library for another post 🙂

The Problem

Our friend IE! Now I know that it means well but good intentions alone are of no help! For some strange reason, when IE saw the HTML stream we threw at it for rendering, it decided to use “Quirks” mode for rendering along with the browser mode chosen as IE7 (even though we were using IE10). This was evident when we popped up IE’s developer tools by pressing F12 on the tab which had the website in question open:


Now, when Google chart API sees that it has to deal with an “old” version of IE, it tries to adapt by sending back VML tags in an iframe for rendering graphs. (details HERE). While it is all with good intentions, where this adaptation blows up is if someone clicks on the charts and drags – the charts scroll up in the iframe and may even disappear with no way to click and drag them back to where they were!

The Solution

Easy: Tell all your users to quit using IE until it grows up! (wish this was an option :))

In the real world though, we needed to find a way to tell IE that it is dealing with grown ups and can just do what it is expected to – use standards mode and the best capabilities of the current version (IE10 in this case) to render our stuff! It turns out, there is an X-UA-Compatible header that is honored by IE when trying to choose a browser mode and document mode while rendering. This header may be added via a custom HTTP module (if you’re on ASP.NET) or via IIS Http headers settings. For details on how a custom Http module may do this, refer to my previous post where I show how one may tweak HTTP headers using the PreSendRequestHeaders event. For IIS settings, read on.

Assuming you are running a version of IIS 7 or above (you have Windows 7 or Windows Server 2008 or above) here’s what you’d do:

  1. Start -> Run, type in inetmgr and click OK
  2. You’ll see the IIS management console like so:


Click on the machine name node (Sudh in the above figure). In the right pane now, you’ll see several options depending upon your IIS  and ASP.NET installation (i.e. what all you chose to install while setting up IIS and ASP.NET). The option of interest for us is under the IIS section in this pane and it should be called “HTTP Response Headers”:


Double click on the “HTTP Response Headers” icon and you should be taken to the configuration screen in the same right pane. Right click on the empty area or click “Add” from the Actions pane on extreme right to bring up the “Add Custom HTTP Response Header” dialog:


Add this in the name field: X-UA-Compatible

and this in the value: IE=edge

What this tells the browser is that it should use Document mode as standards and highest browser mode it is capable of. Details about the header and its values can be found on MSDN.

Once done, we revisited the website served by this IIS instance and popped up the dev tools in IE (F12) and as expected,  Document mode showed standards Browser mode said “IE 10 Compatibility”. Good news was that the iframes were gone!

Now this works alright if your are on IE10, if you are on a lower version, it is not as straightforward to get rid of the iframes. In such a case, you’ll need to leverage JavaScript/jQuery to look for the iframe and fix scrolling to none everytime these iframes are rendered.




You can also add this or any other headers through the system.webserver config section in the applicationHost.config located by default at “%WinDir%\System32\Inetsrv\Config” like so:

 <clear />
 <add name="X-Powered-By" value="ASP.NET" />

This can also be done programmatically as explained in the IIS developer center.



       EDIT 2


Turns out you can also include X-UA-Compatible as a meta tag in your master page/default.cshtml like so:

<meta http-equiv="X-UA-Compatible" content="IE=Edge" />

This technique is the easiest to implement especially on shared hosting where you may not be able to tweak IIS settings too easily. A great discussion on stackoverflow can be found here.


hope this helps,

Further reading:

Values of X-UA-Compatible and interpretation

Defining document compatibility in IE

Enabling Standards mode (Read for understanding how the box model deviates when document mode changes)

Stack Overflow discussion (Concludes that once document mode is standards, you should be good)

Happy Coding!

Tagged with: ,
Posted in ASP.NET, Internet Explorer
One comment on “Force Internet Explorer to use standards mode: X-UA-Compatible HTTP header

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

  • Comic for March 28, 2017
    Dilbert readers - Please visit to read this feature. Due to changes with our feeds, we are now making this RSS feed a link to
%d bloggers like this: