WWW FAQs: How do I make my site look good at any size and resolution?

2006-10-18: Designing a page to look good at any screen resolution or physical screen size isn't quite as painful as it sounds. You just need to decide what sort of layout you're going for, how to address the question of your page background, and how you want your text and images to behave. Text is probably the trickiest issue, but understanding it well can lead to gorgeous results.

Layout Issues

Do you want your layout to expand to fill larger screens? Or do you want your layout to stay the same size, and just center it nicely on larger screens?

Trivial web page layouts— those that simply contain text and images in paragraphs, without multiple columns— usually don't need any changes to work on larger screens. The text automatically flows to fill the browser window. Problem solved. But if you're asking this question, you are most likely using a more complex layout.

Fortunately, I've tackled this issue for you already. For everything you need to know about creating fixed and variable-width page layouts that cope appropriately with browser windows of different sizes, see the article how do I create a three-column CSS layout?

Background Issues

A related challenge is convincing a background image or other background to fill a larger browser window, or at least prevent unwanted repetitions of the background.

In theory, this is fairly easy in CSS3. But current browsers don't support CSS3 very well.

For solutions and workarounds for these problems, see my articles how do I make a background image fill the browser window and how do I stop page backgrounds from scrolling or repeating.

Text and Image Size Issues

Large displays, and displays with a high resolution (many pixels in total), can easily lead to "tiny text" problems. And naive attempts to fix these can lead to an unusable web page on smaller screens. I'll explore the problem and its solutions. But first, it's crucial to understand the concept of DPI (Dots Per Inch).

DPI: Just How Gritty Is The Nitty-Gritty?

DPI, or Dots Per Inch, is a measurement of how many dots (pixels) appear per inch on the screen. You can calculate the DPI of your screen by dividing the number of pixels across by the actual physical width of the screen, in inches. For instance, if your display is set to a resolution of 1024x768 and your display is 14" across, then your DPI is approximately 73.
Don't forget, I'm talking about the width of your screen here. The advertised size of your screen is a diagonal measurement.
High-DPI displays are a good thing, because they display text much more attractively and clearly than low-DPI displays. But problems begin when web designers pick a font size in pixels. The higher the DPI, the tinier those pixels are... and the tougher your pages are to read!

Why Pixels Aren't Perfect

If you have specified your font sizes in pixels, like so:

body {
  font-size: 10px;

Then a character will be the same size in pixels regardless of DPI. When the screen has a very DPI, this displays a large amount of information at once... at the cost of squinting on the reader's part, and unexpected effects on layout.

I've just said that a pixel in CSS equals a pixel on the screen. But that's not quite always the case. The CSS 2.1 specification actually states that "If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values." The specification also says that 96 pixels per inch is the "standard" pixel size.

In English, that means that if the DPI of the screen or other device is very high— not 72 dpi or 96 dpi or perhaps even 120 dpi, but something more like 150 or 300 dpi— then it is appropriate to scale CSS pixels up to two or more screen pixels. In practice, however, most current web browsers do not do this, at least not by default. A pixel is a pixel is a pixel, on the screen. Printers must always scale pixels up, because they produce output at a very high 300 DPI.

Let's Get Physical: Measuring With Points

Many CSS designers get excited when they discover that they are not limited to specifying the size of an element in pixels. You can also specify the size in inches, centimeters, millimeters, "picas" or "points." A point is 1/72nd of an inch, while a pica is 1/12th of a point.
All of the physical units are essentially the same, because they all measure physical size. So when I talk about points, keep in mind that my comments also apply to inches, centimeters and the rest of the physical units.
Points sound great, don't they! Why worry about the number of pixels per inch when you can just specify how tall the text should really be?

Unfortunately, it doesn't really work that way. A freshly-installed Microsoft Windows XP system assumes that 96 pixels make up an inch... no matter what the DPI of the monitor really is. And MacOS X systems assume that 72 pixels make up one inch (which is coincidentally true, or very close to it, on my iMac). You can see this problem on my CSS points demonstration page (opens in a separate window).

So, are points useless? Well, not entirely. You can choose to use them, and point out to your users that if text appears too small, they can always tell Windows what the true DPI of the monitor is.

Users can set the dpi (dots per inch) of their Windows display by doing the following:

1. Start -> Control Panel -> Display

2. Pick the "Settings" tab

3. Click "Advanced"

4. Locate the "DPI setting:" option and select "Custom setting..."

5. Hold up a real ruler to the display and drag the ruler on the screen until they agree!

6. Click "OK." You will be prompted to restart your computer.

Macintosh Firefox users can set their DPI via the preferences option on the Firefox menu. (Windows users can do that too, but it doesn't have any effect— they should follow the steps above instead.) Unfortunately, Safari does not currently support manual DPI settings at all.

Honestly, most users probably won't choose to fix their dpi setting, and some will not like the way it affects the appearance of the entire Windows desktop. Other applications are affected, which the user might not like, and the system tray in the lower right corner resizes its icons in a crude and unattractive way. But at least you are giving them a choice that they wouldn't have if you used pixels for your layout.

Here's an example of how to specify a text size in points with CSS:

body {
  text-size: 12pt;

We Have An Image Problem

What about images? By default, images appear "pixel for pixel" on the screen (scaling up only for printing, at least in 99% of cases).

It's possible, using CSS, to size an image with points or any other unit. Here's an example:

<img src="myimage.png" style="width: 72pt; height: 72pt"/>

The image is scaled to 72 points across by 72 points down (which of course is one inch square).

However, keep in mind that web browsers don't do a great job resizing images for you. You can ease the pain by making sure the original image has a higher resolution than what the user will finally see, but the results are pretty ugly even then. For this reason, it's usually best to accept that your images are simply not going to be scaled up along with your text. Hopefully this situation will improve in the future when scalable SVG vector graphics become a widely accepted part of the web.

Another big disadvantage of points is that, while they can solve the DPI problem (if, and only if, the user takes the time to set up their computer that way), they don't solve the physical size problem. What if the user is looking at your website on a small device, like a "hiptop" handheld computer? With points, you can specify that the banner across your site should be twelve inches wide... but that just forces the hiptop user to scroll horizontally. There's a better way.

The Relative-Size Option

Pixels get smaller as resolutions get bigger. And points are defined in terms of pixels, unless the user goes well out of her way to tell the computer otherwise. Yuck, what a mess! Is there no other option?

Fortunately, yes. We do have one more option: leaving the user's font size alone... or defining font sizes in relation to the user's normal font size. All web browsers are designed to show text at a reasonable size if a page makes no attempt to control how large the text will be. In fact, in the early days of the web, this was the normal way to design things. Designers understood that heading elements like h4, h3, h2 and h1 would display at increasingly larger sizes. Later, designers used the font element's size attribute in a similar way; size="1" was smaller than normal, size="2" was normal, and size="6" was equal to h1. In CSS, we can get the same effect using relative sizes.

Consider this CSS code:

  font-size: 200%;
  font-size: 70%;

Here we set up CSS classes for very large text, and for smaller text. We don't try to "force-feed" a physical font size to the user, but we do exercise relative control. And in many cases, that's perfectly sufficient. As of this writing, Microsoft uses this technique quite effectively on their MSDN reference pages— which formerly suffered from a reputation for illegibility on non-Windows screens.

The Image Problem Returns

Although it is possible to use percentages to size images in terms of the enclosing absolutely or relatively-positioned element (in practice, this usually means the browser window), it is not recommended. As with sizing an image in points, sizing an image in percentage terms results in low-quality resizing. It's better to accept that your images will appear at their actual size in pixels, and that your text won't necessarily always line up with an image in the same way. Of course, clever designers will find cases where the resizing behavior does have an acceptable appearance.

Boxes and Borders, Oh My

My CSS points demo demonstrates that we can size a div element using points. We can also size a div "box" with percentages:

// Height percentages work only if the
// enclosing element's height is
// explicitly defined (see CSS standard)
html, body {
  height: 100%;
.box {
width: 10%;
height: 10%;
background-color: red;
color: black;
<div class="box">
10% x 10%

However, the resulting box will not be square.

Why? Because, for width, 10% means 10% of the containing element's width. And height means 10% of the containing element's height. The browser window isn't square, so our box isn't either. This probably isn't what you had in mind.

Is there a solution? Yes! We can size our box in terms of the font size, rather than the browser window size. We'll do that using yet another unit of measurement: the "em." An em is equal to the current text font size. So a box with a size defined in "ems" will scale up or down depending on the font size of its container.

Clear as mud? Here's an example:

.box {
width: 10em;
height: 10em;
background-color: red;
color: black;
.big {
font-size: 200%
.small {
font-size: 70%
<div class="box">
10em x 10em

What the heck is an "em?"

You would be forgiven for thinking that an "em" is equal to the width of the character m, or perhaps the character M. That is one historical meaning for the term, but it's not what "em" means in common use today and it's definitely not what "em" means in CSS.

The best explanation of "em" comes from traditional print typography. Imagine a series of type blocks (stamps), one for each character in the complete font. To make sure that characters line up on a common baseline, all of these type blocks are of the same height— tall enough to accommodate the characters with the highest ascent above and the lowest descent below the baseline (think of the accent on <eacute> and the descending loop of g).

That height is one "em." And it is also what we are specifying when we set the font-size CSS attribute. When we don't force our own setting for font-size, or we change it relatively with percentages, the size of an "em" depends on the user's default font size... which is usually easy to read on their display. And that's what we want.

For more information about the "em" unit, see the excellent Wikipedia entry for Em (typography).

"Ems" aren't just for sizing div elements. You can also use them for border and padding attributes, which I recommend, and for images... which, for all the reasons I mentioned earlier, I don't recommend. The image quality will suffer too much when it is resized by the browser.


Text can be made to behave. Boxes and borders too. Images... not so much.

Someday vector graphics should be a standard, everyday, fully-supported part of the web. But right now, it isn't. So you'll have to bear in mind that though your text is scaling to match the user's preference or physical monitor size, your images are always going to appear "dot for dot" unless you force the browser to resize the image... which doesn't look good.

Some designers conclude from this that they must size their text in pixels as well. And for some page designs, at least, they're right. In such cases a centered, fixed-width layout may be best.

But for those whose pages are primarily driven by text and the desire for legibility, there are compelling reasons to consider relative font sizing.

Of course, you can mix the two. Some page designs benefit from the best possible legibility in one area, but require a guarantee that the text will fit into a particular box in another (and that the box will fit into the browser window, and so forth). In these cases, you can combine pixel measurements and relative measurements for the best possible results.

Legal Note: yes, you may use sample HTML, Javascript, PHP and other code presented above in your own projects. You may not reproduce large portions of the text of the article without our express permission.

Got a LiveJournal account? Keep up with the latest articles in this FAQ by adding our syndicated feed to your friends list!