The Definitive FAQ on Screen Resolution

Frequently Asked Questions About Screen Resolution

The term resolution when used in this FAQ refers to the monitor size in pixels, e.g. 800x600. Technically “resolution” is a measurement of dots per length unit (e.g. 96dpi), but since “everyone” use the term “resolution” while meaning the former we’ll use it in this FAQ as well.

Can We Drop 800x600 Now?

There still is and will be people who use 800x600 resolution, either because of hardware limitations, sight impairment, or personal preference. Even if everyone used a higher resolution that doesn’t mean that the browser viewport (the area in which your Web page renders) is as wide as the available screen area. The higher resolution people have, the less likely it is that they browse maximized. The browser window is basically more or less the same width regardless of the screen resolution, it’s just that the user has more available screen space for other things at the same time.

Some users also like to have a sidebar open while browsing (which can take up hundreds of pixels). Others might want to browse with two windows side by side, which means that with a resolution of 1280x960 each window can only be 640 pixels wide.

There are also some PDAs that have a 800x600 screen resolution, and use CSS “screen” media for Web pages.

What’s The Optimum Width You Can Use for 800x600 or 1024x768?
There is no consensus on a holy optimum as far as we can tell. Because of scrollbars, borders, snappers, etc., and because the browser window might not be completely maximized, you should probably subtract 20–50 pixels.

Which is The Most Common Screen Resolution?
As of early 2007, and according to the statistics we’ve seen, the most common screen resolution is 1024x768. But this information is not very useful; what is more interesting to know is the browser’s viewport width. Your Web page renders inside the viewport, not on the entire screen.

Different CSS for Different Resolutions with JavaScript?
It is possible to get the available width with JavaScript, apply different style sheets on load and on resize, but this is not a very good approach, both because it relies on script (which can be disabled or blocked by firewalls, etc.), doesn’t perform very well, and can be done much simpler and more performant with just CSS using a fluid/elastic hybrid layout. Changing the layout when the window is resized can also cause usability problems since the user can loose track.

If you want to have a different layout on handhelds then JavaScript is not an option, because most mobiles don’t support JavaScript in the first place. You should use CSS media queries instead (e.g. media="handheld").

Fixed vs. Fluid?
Fixed width means that the width is specified with a measurement that doesn’t adapt to the browser width nor scale when text is resized (most often specified with px). Some designs “require” a fixed width to some extent, mostly because of heavy use of images, or are just simpler to implement using a fixed width. However, with wide browser windows the site becomes relatively narrow, and with narrow browser windows the page is too wide, resulting in a horizontal scrollbar. Additionally, since the user can resize the text, the line length becomes too short at large text sizes, and too long at small text sizes. If you have only done fixed width layouts in the past then we encourage you to take a closer look at the alternatives below.

body { width:760px; }

Fluid width means that the width adapts to the browser width (either using the keyword auto or using percentages). With this type the user has control of the line length: simply resize the window. The typical argument against fluid width is that people who use wide browser windows may get too long line lengths. This might not necessarily be a disadvantage however; in some cases long line length results in faster reading, or is just preferred or even needed because of certain types of reading disabilities. People who prefer shorter line length can always make their windows narrower.

body { width:95%; }

Using a fluid maximum width on images is very useful to make sure images don’t break the layout or cause a horizontal scrollbar in a fluid (or elastic) layout. As the column gets narrower, the image will scale down, and the height of the image will stay proportional (given you don’t use the height attribute in the markup; if you do, try height:auto in the style sheet).

img { max-width:100%; }

Elastic width means that the width scales when the text is resized in the browser. This has the advantage that the line length doesn’t get too long, regardless of text size. The disadvantage is that it may become wider than the viewport, resulting in a horizontal scrollbar.

body { width:60em; }

A hybrid is a combination of the above, for instance using an elastic maximum width and otherwise fluid (referred to as fluid/elastic hybrid).

body { max-width:60em; width:95%; }

Different situations and audiences require different approaches. However, a fluid/elastic hybrid has the all the perceived advantages of both fluid and elastic while at the same time avoiding the disadvantages (except in the case where long line lengths are preferred), which is thus a good choice in most cases if the design allows for it. If not, you can still use a fluid/fixed hybrid, with fixed minimum/maximum width and fluid in between, which at least avoids the horizontal scrollbar in the range where it is fluid.

More specifically, fluid and elastic works well when the column is mostly text. If you e.g. have a fixed width sidebar (with mostly text), then as text is resized the line length quickly becomes too narrow (long words might not even fit, which might be a problem with languages that have many long words). If you have a column with only or mostly images (and you don’t want to scale them), then fixed width might be best; otherwise you might crop the images or waste space if the column is wider than the images.

For IE6 you can either just fall back to fluid or fixed, or you can use [post=2041241]expressions[/post] to simulate support for min-width or max-width. (Those properties are supported in IE7.)

Further Reading

Agreed, the resolution should at least try and adapt for the viewer regardless of their settings

That’s an interesting attitude to take. When I design a site, I want to make it available to as many people as I can. For the same reason as I don’t use microscopic fonts, or clashing colours, or prevent people using IE6, or write in Latin … I am not going to make it unnecessarily difficult for people with narrower browser windows to use the site.

For people to use your website should not be a privilege that you grant or deny - at least, not if you want to do business. Closing the door on a large chunk of people for no good reason is a pretty dumb thing to do. They’ll take their business elsewhere, and it’s you that loses out, not them. You think it’s just about technology? There are lots of reasons why people might have a narrower browser viewport - they might be using an old office computer that can’t be upgraded; they might have bad eyesight and need it pumped up to that size to read it; they might have large screens but not maximise the browser (I run 1280×1024 and I rarely maximise the browser viewport, it’s just too large to be comfortable for text). But whatever the reason, it’s up to the user to decide what setup they want to run.

<sarcasm>You’re right. Clearly anyone who chooses settings different to yours is not worthy, and you shouldn’t waste your time making your site work for them. After all, it only matters that it works for you…</sarcasm>

But hey, the point of this sticky was to give readers advice and all the good reasons not to specify a width more than 800px. If you’ve read all that and you still want to ignore it, that’s your lookout. :frowning:

I’ve almost completely stopped building sites within 800x600. At this point those people who still run at that resolution are well used to seeing sites wider than their monitors. If they are ok with this and don’t want to upgrade their settings then I’m fine with it too.

old post yet still relevant, more and more device will be available in the future, the designs need to adapt them

Straight and to the point. Very good post!

There was a study that Sitepoint references in its News Wire that shows the common view size, perhaps you should add that to the further reading section as well. I’ll try to dig it up for you.

Nice job as usual Simon :tup:
I would also insist on Roger Johansson’s article!! it is a highly recommended reading IMO :nod: :smiley:

Very interesting, great job!

Good summary Simon,

I agree with it all and it’s time for me to experiment some more with fluid / elastic hybrid layouts…

Cheers, :tup:

Interesting read. I would say depending on your audience it may be worth dropping 800x600. But it depends on your audience and purpose.


Very Nice indeed.


This is a great resource for what size you should make your site.

Your “fluid maximum width on images” tip sounds useful. I didn’t know about it - thanks!

Quite a few interesting facts and opinions in this article (I believe I can call it that). A job well done!

I’m one of those who switches between maximized and not, I usually unmaximize my browser when I across a fluid site like sitepoint here because the width of my screen is 1920px making it very wide and very hard to read long lines.

Nice one Simon.
I too haven’t tried the percentage width on an image - I’m going to test that later :slight_smile:


Doesn’t seem to work in IE6 >.<

Indeed it doesn’t. IE6 doesn’t support ‘max-width’.

It is possible to implement with expressions, but it only seems to work when the parent element has “layout”. The following expression will check if the parent element has layout, and, if so, set a maximum width to 100%. (Without the check all images whose parent doesn’t have layout will become 100% wide; with it they stay unaffected.)

img { max-width:100%; -width:expression(((w = typeof(w) == "undefined" ? new Array() : w)&&(w[this.src] = typeof(w[this.src]) == "undefined" ? this.clientWidth : w[this.src]))&&(this.parentNode.clientWidth <= w[this.src] && this.parentNode.currentStyle.hasLayout ? "100%" : "auto")); }

The “w” variable is so that it doesn’t forget the initial size. The [this.src] thing is so that it works for different images.

The dash in “-width” is a hack to target IE6 so that it doesn’t affect newer versions of IE that support ‘max-width’ natively.

You can’t have height=“” attributes in the markup though.


It doesn’t seem to perform very well though; when applied here on SitePoint IE6 hangs. If you experience such problems you should probably make the selector more specific so that it only applies to the images you want to scale, and then it should work well.


Straight and to the point, and all explanations were in layman’s term…A great job, especially for someone like me who’s a total moron.

Interesting read, thanks for sharing. I suppose there’s a place for both liquid and fixed width if the information presented calls for it (like tabular info might look best fixed width).