Take the 2-minute tour ×

I'm having (yet another) strange problem with IIS. When viewing an ASPX page I've designed on my local machine by browsing to http://localhost/page.aspx the page looks as expected (and looks the same in IE, Firefox and Chrome. If I change localhost to my_hostname the page is rendered with a disabled vertical scroll bar.

The behavior was first noticed when I published my site to our live server and saw the same discrepancy. After beating my head against the wall I tried what I described above and was able to duplicate my "problem". So with that, I turn to you guys.

This wouldn't really be an issue (save for the cross-browser inconsistency) except that this screws up an "absolute"ly positioned <div> moving it partway off the screen instead of being centered like it should be (and is when viewed any other way except in IE when the address is anything but localhost).

As another test I added a new aspx page to my project and didn't add or change any of the default code. If I browse to the page using localhost there is no scrollbar. If I browse to the page using my_hostname the scrollbar is there. Whatever the difference is it's making IE's processing of CSS get screwed up, to the point where at first everything works the same in all browsers I'm testing in, and afterwards IE just makes up its own rules. This is incredibly frustrating and I'm really hoping I'm just doing something wrong and it's not an inherent problem.

share|improve this question
I've been able to work around the CSS problem by moving my <div> out of the block that it was in and setting a negative margin. Not a graceful fix by any means, but such is life when ensuring cross-browser compatibility. It would still be nice to figure out why it's so different. –  maik May 17 '10 at 21:16
add comment

5 Answers

up vote 8 down vote accepted

I know this is an old thread, but I just hit the same problem. If you are using IE8, the issue may be its Compatibility View. By default, sites in your local intranet - but NOT localhost - are rendered in IE7 compatibility view. More info here:


Unfortunately, that doesn't help get rid of the disabled scrollbar, but it does explain the discrepancy.

share|improve this answer
That's excellent. Thanks for finding and posting the insight into the issue. –  maik Oct 29 '10 at 18:58
It seems that IE9 does that as well. In Page > Compatibility View Settings dialog, uncheck "Display intranet sites in Compatibility View" and it'll render like it does on localhost. –  Mike Caron Jan 17 '13 at 18:49
add comment

CSS shouldn't be affected by the URL. Any chance you have hidden text with the URL somewhere in the body that is causing it to shift? If you view the source of the file in both situations using a tool like http://www.quickdiff.com/, is there anything different between them?

share|improve this answer
That's the exact thought I had, which is why the problem appears to defy logic. The only thing I can come up with is that IIS is doing something special based on whether the request is coming from localhost or not. If I use localhost, 127.0.01, my IPv4 address or IPv6 address it renders the same (without scrollbar, etc.). If I use my computer's hostname or access it from another computer it renders with the scrollbar. I did initially examine the source with my eyes and didn't see any differences, and just verified that using quickdiff.com. <3 IIS :( –  maik May 20 '10 at 15:21
Definitely strange. How about a quickdiff on the css files? The other thing to check is firebug or fiddler2 to see if the headers are different. That will show what IIS is sending in the headers. –  Scott Forsyth - MVP May 20 '10 at 16:55
Part of my debugging was moving what little CSS I had into the aspx file instead, so there's nothing special going on in that department. I'll check out Fiddler and see if I can see any differences. –  maik May 20 '10 at 20:32
Fiddler shows differences in the request and response headers. It doesn't look like anything spectacular, but maybe IE is making a rendering decision based on something there... In the request headers, the only difference is that in the my_hostname request headers, the Authorization header comes before the Host header while it's the opposite in the localhost request. In the response headers Persistent-Auth is set to false in my_hostname and true in localhost. The encoded token in WWW-Authenticate is also significantly longer in my_hostname than localhost, but the method is still Negotiate. –  maik May 20 '10 at 20:45
Any chance that in IE the site is set to a different zone? i.e. with one URL it's trusted and with another it's not? That would only affect IE though. –  Scott Forsyth - MVP May 24 '10 at 13:12
add comment

The problem resides in the IE8 compatability view settings. By default, intranet sites (your server) are displayed in compatibility view. To override this behaviour you should add the following code to your code behind of your aspx page.

protected override void OnPreInit(EventArgs e) {


It worked for me.

share|improve this answer
This goes right along with the compatibility stuff Claire mentioned above. Thanks for this answer! –  maik Mar 17 '11 at 16:42
haha I just got this problem, and I was heading here to put a post thinking "people is gonna think I am insane". Thanks a million! –  NullOrEmpty Sep 6 '11 at 15:04
Alternately, you can add Response.AppendHeader("X-UA-Compatible", "IE=8"); to the Page_Load method in your Site.master.cs file. –  Nick Chammas Jun 18 '12 at 16:02
+1 This solution helped me to solved my same issue, awesome!! –  Somebody Oct 2 '12 at 13:16
add comment

In IE9, sites running on localhost are automatically rendered in Compability Mode. To change this (default) behaviour, do this:

  1. If not activiated, activate the toolbar Command
  2. Click Page > Settings for Compabilitymode
  3. Uncheck "Display intranetsites in compabilitymode"
share|improve this answer
add comment

Here's a post on StackOverflow about this

basically change the top of your HTML Layout or MasterPage(after the <%@...%>) to:

<!DOCTYPE html>
share|improve this answer
add comment

Your Answer


