, ,

So you are running the latest version of Internet Explorer and you’re thinking: I should get good performance and better User Experience when accessing a SharePoint site. After all, Microsoft® has done allot of work to bring that browser closer to being standards compliant. Wrong!

SharePoint’s User Interface (UI) is a creature of habit. It’s coded to target specific versions of Internet Explorer (IE), which makes me think some group at the company is stuck in the early 2000’s. If you take a look at SharePoint 2010 page source, you will see this meta tag in the section:

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

This essentially tells Internet Explorer to render the page using the IE 8 rendering engine even if the current version of IE is a more recent one (ex. IE10 or IE11).

SharePoint 2013 is no better. Despite still not using the HTML5 standard header, it instructs IE to render the page using IE10:

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

This is why I always strongly suggest using a non-IE browser when using SharePoint.

In working an issue found by a user of MyBoarda SharePoint task management app that I have a available – I found that the problem was due to the page being rendered in IE8 mode. If I brought up the debugger in IE11 and switched the rending engine to EDGE (latest version), then the issue would not occur. Rather than spending time trying to find a code workaround for this version of IE, something I have decided to stop doing long ago, I instead researched if there is a way to force the MyBoard app page to be rendered using IE EDGE, but at the same time not impact the entire site.

Changing the Master page to include the meta tag to render the page in IE using the latest engine is not an option, since MyBoard is an app whose main feature is that it can be quickly used from any site in a SharePoint (it simply requires it to be placed in a Document Library). It’s also only a single page, thus impacting an entire site for the benefit of only one page is not good. There are also several posts on the web documenting the negative impacts to a SharePoint site if this is done – perhaps the main reason that SharePoint, by default, sets its rendering engine to a specific version of IE.

So what do we do? What options do we have?


The solution is to use a simple HTML file (I call it my “IE Loader”), which loads with a meta tag that instructs IE to render in EDGE mode, and show the MyBoard app page in that iframe. The reason this works is because IE can only set the rendering engine once per page load. Once set (by the “top” page) it cannot be changed and thus all pages loaded through an iframe are forced to EDGE mode.

Here is the HTML:

This file, named ie.aspx (yes, file extension is, and needs to be, ‘aspx’ instead of ‘html’), can simply be uploaded to a Document Library and it will load the file defined at line 26 (var url) by default.

The JavaScript code simply ensures that the iframe takes up the entire width and height of the browser window, and maintains those dimensions even when window is resized, thus providing the allusion to the user that its actually not in a frame. In addition, it supports providing the URL to the page that should be loaded via the ‘search’ parameter field. Example: the following URL


will load the page at /sites/sitename/documents/myCustomPage.aspx in the iframe rendered using the latest version of IE.

A default page to be loaded should be set so that if a user clicks on this file they will not get an alert.

Some caveats and tips:

  • Displaying the page in an iframe means that all links that the user clicks on, will also be displayed on the iframe and potentially breaking form functionally. To get around this, one can further enhance the code above to “break” the iframe if the URL is changed to one that is not the page that was meant to be displayed in an iframe.
  • For non-IE browsers that may access the ie.aspx page, it may be desirable to also break the iframe and just show the intended page directly.
  • If using this workaround on a controlled page, code can be added to that page to detect if IE is being used and if so, whether the ie.aspx page is the one displaying it.

So the solution here will trigger IE to render a single page using the latest version of the browser while leaving the rest of the site intact. This approach also does not require any structural change to a site or the involvement of an IT department to implement. In my current use of it, I have additional code that further integrates the “IE viewer” with the app I have loaded in the iframe.