How to Size Text in CSS

by Richard Rutter

96 Reader Comments

Back to the Article
  1. I been asking this question to myself a thousand time and this is one of the best examinations of text sizes. Given me great insite into building my next website.


    Copy & paste the code below to embed this comment.
  2. Not this argument again. All I will add is this: what if the text size chosen is considered too small by the user? Who dictates that they cannot choose to enlarge it? No-one should!

    My view on it is this:

    You should be able to set a minimum text size in your browser settings, so that no text will ever be rendered smaller than, eg, 12px (or whatever else you consider the minimum that you can read). This would be the equivalent of a user !important, and would override anything the website says or does.

    You should be able to zoom the page (text, images and layout) to enlarge or reduce it as appropriate. Opera seems to do this better than IE7, but that may just be because I’m more familiar with it.

    The designer should be able to make concrete layout suggestions that the browser will respect where possible. That means that there are some occasions where the pixel size of text is important to the layout – eg, because it has to fit with images that are necessarily sized in pixels.

    That’s why we should not use px for font sizing as a matter of course – because it should be reserved for those occasions when you absolutely need the text to be displayed at that size – 99.99% of the time, ems or %s are the right way to go.

    The main reason that browsers do support resizing of text in px is because they are trying to compensate for the idiocy of designers who have inappropriately specified text in px across the board.

    Copy & paste the code below to embed this comment.
  3. I personally don’t understand some designer’s desire for such pixel perfect designs. Web pages should be more fluid than that (of course there are exceptions). I personally use em and fix the IE issue by setting the body font-size to 100%, as was mentioned in an earlier post. For the main content I generally use 1em because that should be the default. I don’t do any .865em or whatever, I just make things relative, often .9em or 1.5em.

    I don’t care much for the zoom option in some browsers, but I do think it would be good for browsers to have both options of zoom and text size in-/de-crease.

    Just as another vote, I find ALA text size too small. I’m currently viewing the page 3 notches up, though my eyes are tired, but usually use 2 notches for the site and I’m in my mid-20s and have good eye sight. Too many sites are decreasing their font-sizes. The default 16px is there for a reason like others have stated. Though I find it funny that the texarea box for writing a comment is quite a bit larger than all of the other text on the page.

    Overall, nice article and good things to think about.

    Copy & paste the code below to embed this comment.
  4. I first settled on pixels for font sizes after reading the original release of Zeldman’s DWWS. Ems have a certain attractiveness, in that they let you set a base size and then set everything else in relation to that. That flexes nicely, if I want to rework a sheet with a new base size and have everything change proportionally without having to touch all declarations.

    However, this is the sticky bit that I completely don’t understand: What’s with the compounding on nested items? Why in the world would I want to embrace a typesetting standard that requires me to keep track of where in the document hierarchy a piece of type is and then CALCULATE the proper setting to keep the type AT THE SAME SIZE? That’s crazymaking. The push for standards was about stopping the madness, and it seems this is just an exchange of one form of madness for another. “Stop all the browser code forking!” (Hooray!) “Compute arcane, essentially meaningless size settings (1.375em
    ?), and make sure your nested items have their own settings (for each level of nesting) to compensate for compounding!” (Hooray?)

    This is progress? All of this to accommodate a segment of users who have chosen to use a tool that doesn’t do what they want? That sounds like a personal problem. Whatever happened to individual accountability? Why should an industry adopt an awkward, recursive practice of font sizing to fix something these users should be fixing themselves? Any self-respecting programmer would snort and walk away. Any self-respecting designer would just decide you’re crazy.

    Perhaps this is related to the notion that several have brought up about the rigid baseline grid being a typographic anomaly that has grown up in the soil of typographic ignorance on the web. Maybe those who are valuing “upsizing for all! (even apathetic IE 6 users)”? over and above sensible methodologies are mostly politically correct nouveau-web fanboys who are ignorant of the older, and more established streams of thought coming from the worlds of typographic design (dating to at least Gutenberg), and programming (Donald Knuth, anyone?) that inform these issues.

    I think I’m sticking with pixels. Page zoom is a good solution. IE6 users are the only ones left out. Anyone with vision problems should do the research to solve their problem by changing browsers to one that does what they want. If they don’t, then it’s their bad, not mine. Web makers shouldn’t have to jump through flaming hoops backwards to accommodate apathetic users who want to complain about type sizes when the problem is their passivity towards solving their own issue.

    Copy & paste the code below to embed this comment.
  5. I try avoiding putting styles (like fontsize) on the P-tag because CMSs don’t always relyably produce the desired clean HTML-output. Sometimes the editors used in CMSs produce a P-tag around the content, sometimes they don’t. If you try to catch this in your templates by putting a P around where the content is loaded, you will get invalid code when de editor does produce the P (P within P).
    So I try to put these styles on the surrounding DIV. Did anyone work out the alteration of this code to suit this need?

    Copy & paste the code below to embed this comment.
  6. Someone had to do this testing – I’m glad to say that my non-scientific testing correlates to richards findings. Now I can rest assured that there is a proper way to set sizes in css – ems baby, ems.

    Plus, I think guttenburg would be happy. The pixel shall not win this battle. ;)

    Copy & paste the code below to embed this comment.
  7. I used this article while designing a site I’m working on now.  I have always had problems with (em) and cross browser quirks, this is great for make those readily apparent.  Previously I had giving up on em just because of all the browser issues associated with it.  This method has proved flawless so far on the site, and I will probably use it on all subsequent sites I design.

    Copy & paste the code below to embed this comment.
  8. Another awesome piece of research and testing, cheers Richard. If the article upsets me in one way, it’s in realising that this sort of article should only be enforcing the test we’ve already carried out…unfortunately time and resource doesn’t always permit so it’s thanks to you again – this article will be passed around our developement team and adopted as apart of our coding standards.

    Copy & paste the code below to embed this comment.
  9. Using ems (or any percentage method) to resize fonts pretty much guarantees sub-optimal design and legibility. This current “received wisdom” of web design, focusing so hard on technical aspects, generally fails to recognize the nature of pixel-rendered fonts.

    Fonts cannot be resized successfully simply by using ems or any other percentage method.  They are not like svg objects.  Fonts are an art form and the size in pixels is critical.  If you render a font at 80% that was drawn at, say, 18px in height, you do not get the same font 20% smaller.  You get a different font that is usually less legible and less attractive, and is often downright ugly and hard to read. Resizing fonts by using percentage reduction is tantamount to resizing images by using percentages.

    If you want your typeface to look good at different sizes, you have to retain style control.  This means using fixed font sizes and providing alternate font sizes yourself, which is fairly easy to do through a server-side script.

    Copy & paste the code below to embed this comment.
  10. Thanks for posting up your article. I’ve   used the test pages you provided and looked at them in FF2/IE7 on a PC. Using the EM method you’ve described, there is still a large font jump in IE7 on the PC. Has anyone else noticed this, and is there a recommended cure?

    Copy & paste the code below to embed this comment.
  11. Fantastic article, but on thing really stuck in my head as I looked thorough the countless screen-shot examples (cant beat pictures), the difference that ClearType makes with browser rendering in comparison to the mac fat’n’furry soft rendering.
    I get that its a personal preference, but wouldn’t it be great if Apple and MS could just agree that fonts should display as they were intended to by their designers.

    Copy & paste the code below to embed this comment.
  12. Hi Richard,

    This is a wonderfull experiment and I would like to thank you very much for sharing it with the world. However I have an objection inregards to your conclusion.

    First please let me draw your attention to what you have here:

    The tests that you have done are based on the following environment:

    1-Tests have been done with limited number of browsers as you pointed it out yourself but they are not the majority of the browsers as you mention in your article.
    2-Tests have been done in two operating systems.
    3-Tests have been done with one font-family.
    4-Tests have been done in a two column layout.
    5-Tests have been done with XHTML strict doctype and charset=utf-8

    So what is the objection?

    Even though I look at the conclusion of your article positively (and BTW i have experimented myself in some part of my site) however I believe it only applies to your experiment and cannot be generalized as you have generalized in your article.

    Clearly there are other factors which affect the rendering of a web content. The structure of web content and the environment in which the web content is present are the most important part affecting the rendering process.

    As you know It is possible for a content to be rendered correctly in one layout / browser/platform however with problems such as overlaps in the same layout but in different browser/platform or in different layout / browser/platform.

    So if we use another layout or structure other than two column layout or another font-family, etc.  it is possible to see some inconsistencies or it needs to be proved by some more experiments that there are no any inconsistencies.

    So basically it is not enough for a text or any element to be a cross browser/platform text / element. It also needs to act properly in relation to it’s neighborhood preventing any layout stability problems when viewing normaly or when resizing the browser’s window or applying zoom etc..

    That is why I have defined the layout stability on my site located at to address this issue.

    As you can see in my site, I have:(I am aware of that 62.5% thingy :), I have experimented the following too)

    body { font:96%/1.7 georgia,serif}
    Line-height (unitless for body but in ems for the rest of the elements)

    Then I have two sections. 1-Navigation elements 2-Rest of the document.

    I have set the font-size in ems for Navigation elements and no font-size declaration for the rest of the document. That is set for all browsers.

    With the above combination of font-size and line-height,  I have experimented my layout using browsercam’s online service with different browsers including IE6,IE7, AOL, Camino, Konqueror, Different versions of (Firefox, Netscape, Opera, Safari,Mozilla, ) on different platforms such as Windows Vista, Windows XP, Windows 2000 Professional, Linux and Macintosh. The screen captures are available at the following

    My experiment proves that, for my layout and with my test parameters like font-family etc. setting the above mentioned CSS rules turns out to be a consistent cross browser and platform solution.

    However I still can not generalize it and I am still debating on it.

    Any comments in this regard would be greatly appreciated.

    Copy & paste the code below to embed this comment.
  13. @Loren

    I had the same problem and could not figure out the problem.  But since I have a large monitor and bad eyes I changed my dpi to 120.  And apparently IE7 takes that into account when displaying fonts.  All is good now that I switched my font dpi back to 96.

    Copy & paste the code below to embed this comment.
  14. @article base case – "For most people (designers, clients, and their customers) 16px is too large for body text" is a rude and unsupported assertion. While empirically it can be said it is quite evidently true of web designers, the same cannot be said of the other two groups. The "size" of 16px has been creeping down for over a decade as the average PPI has been creeping up. While it may well have been true over a decade ago that most people agreed the defaults were too large, there is no published evidence anywhere I have found to support that assertion against the average current environment. OTOH, there is at least some published support in contradiction “”: and recommending that user default size be respected “”: to be found on other than my own web site.

    Konqueror defaults to a pt size that is less than 16px when the DPI is 96. All IE browsers default to 12pt, not 16px. 16px only appears to be its default as a consequence of the a default M$ system setting of 96 DPI. Use of other than 96 is common on recent and current laptops (which, by the way, have been outselling desktops for several years), which typically have a considerably higher than average PPI and need OEM correction to avoid illegible text on their already small displays. Manufacturers have made 120 DPI a virtual default for laptops. The result is IE and other browsers whose defaults are not set in px give users who have not made further corrections 20px @ 12pt instead of 16.

    @article&more; (Richard R, David L, others) – Line-height set other than unitless is a bad habit. That only unitless carries down the cascade as a factor rather than as a previously computed value is a good thing. It means when zoom or minimum font size are employed by the user’s agent to turn your mousetype into otherwise legible text that that text is not constrained to a space into which it cannot fit without overlapping the text above and below it. See “”: to understand the problem.

    @1 (Kari P) – IE em sizing problems are complicated. As answered earlier, setting a % size on body eliminates IE’s basic compounding problem. What hasn’t been mentioned is that the various browsers round differently. That means the starting point can be different right off the bat, but as they cascade and additional sizes are added, the rounding differences also compound. Take a look at “”: for more detail via a testcase.

    @5+ (James S, more) – No one here yet mentioned a not inconsequential result often encountered on pages using the Clagnut/62.5% method. 62.5% is really convenient only for designers who think they need to size things in relation to this variable and unknown size thing called a px. Invariably these designers prefer text in their work to be a smaller size than average people are comfortable with. For defense against this rude designer behavior, modern user agent makers include functions like text zoom, page zoom, and minimum font size. When text zoom and/or minimum size are applied by user agents based upon the Gecko rendering engine, the ostensibly intended effect is multiplied in a manner similar to IE’s font sizing of ems that aren’t applied against an ancestral % size. The effect is truly overlarge text (based upon the visitor’s preferred size), often producing overlapping and/or hidden (inaccessible content). “”: demonstrates the problem with screenshots, but you can easily see for yourself by setting equally default size and minimum size to a size significantly more than 16px and then visiting a 62.5% site, such as “”:

    @26 (Voyou D) – Please stop repeating the mantra. The defaults stopped being "big" years ago. For most web browsers the default size measured in px has not changed for at least 12 years, and probably much longer. Because of the decrease in average PPI over the years, the apparent default size has been decreasing. To the rest of what you wrote, well said.

    @32 (Adrian D) – It isn’t a little rude, it’s a lot rude.

    @37 (Jason S M) – Not only does changing your browser defaults not not make perfect sense, you’re derelict in your testing thoroughness to not be constantly changing them to emulate the wide range of possible user conditions. There are too many variables in user environments to assume that users have one resembling your own, regardless what the system and browser settings were when you got your own hardware. Assuming any user setting to be wrong and in need of arbitrary adjustment by someone with less than 100% of the situational facts is nothing short of rude.

    @39 (Stephen D) – Web browsers are user agents, not web page author agents. Those incapable of accommodating user wishes and needs are broken. It doesn’t matter what your design requires or the CSS specs seem to say. If I can’t read it, it’s worthless.

    @48 (Dusan S) – Modern open source operating systems can and do detect display DPI, thus rendering text on screen sized in pt exactly the same size as when printed. The problem is that screen resolution falls short of print resolution, while the average distance between text and user’s eyes is considerably greater for screens compared to books, magazines and newspapers. Text on screen usually needs to be physically bigger than printed text in order to be equally comfortable to read, or even legible. Firefox for Linux and Mac do allow a different assumed DPI, but there is no UI for changing it. Type about:prefs in the urlbar, then dpi in the search box to find the pref.

    @55 (Andrej T) – Decimals in font size rules are ignored by IE. 62.5% is treated by it as 62.00%.

    62 (Kendall C) - If you’re in the design business, you’ll probably find yourself back on ALA often. Make yourself a user stylesheet that applies exclusively to it via Gecko’s -moz-document facility and you won’t know about its tiny text until it gets a CSS overhaul that breaks your overrides.

    @68 (Mason B) – If you’re using a decent modern display better than the median, you have enough PPI that small differences in font sizes should produce no apparent qualitative differences. I don’t ever find smaller than my default fonts easier to read, regardless how many px it took to render them, or how good they "look". Indeed, if you render a font at "font-size: 80%" that was 18px in height, what you actually get is a font 64% in size. CSS "size" is only nominal, not real. Real size is a function of both height and width. A 16px character contains around 128 discrete px, measuring around 8px wide by 16px tall. A character box exactly 80% of 18px high would be 6.4px wide by 12.8px tall, providing about 82 discrete px.

    Be part of the solution to the problem rather than part of the problem. Accept that 100% of the default size is best. Personal computers are intended to be personalized. Assuming they have been is the right thing to do, no matter how few have actually had it done. Just because web designers all think browser makers are morons is no justification for assuming smaller is better for anyone other than yourself. If the defaults are too big for you, personalize your own PC, not mine.

    Copy & paste the code below to embed this comment.
  15. Jay’s comment perfectly sums up my feelings on this whole ridiculous practice.

    Copy & paste the code below to embed this comment.
  16. Where can i get the page zoom tool?

    Copy & paste the code below to embed this comment.
  17. I still have doubts regarding the best solution of what type of font to use. Still testing different variations.

    Keep up the good work.

    Copy & paste the code below to embed this comment.
  18. I´ve got much problems with the text size in Ie and Firefox, too.
    But this discussion and it´s including links helps me a lot.
    Thanks everybody

    Copy & paste the code below to embed this comment.
  19. @61 included: “That means that there are some occasions where the pixel size of text is important to the layout — eg, because it has to fit with images that are necessarily sized in pixels.”
    However, there is an easy method to size images in ems – see for example.

    Copy & paste the code below to embed this comment.
  20. You’re right that keeping track of the math percentages with ems can be tricky. Luckily, with a good handful of browsers for testing, and a logically laid out stylesheet, it gets much easier.

    Copy & paste the code below to embed this comment.
  21. Being that I don’t have the grasp of CSS that the author surely does, i’m sure my comments might not be appreciated…..  I am of the opinion that it is best to set the pixel size absolutely as most sites (should) have a significant amount of content.  As a designer, I prefer knowing exactly where every letter is going to appear in relation to every graphic.  It helps me to visualize where images should or shouldn’t go and more.  Of course, I am a bit old school in my methodology, but it is still my preference :)

    Copy & paste the code below to embed this comment.
  22. I liked the effort that was put into this article. That was a whole lot of screen captures and thought.
    Thank you!

    I came to this site as a whole, looking for the answer to a question:

    How can I/we create documents, that might be one or more pages and be shown one any platform (I use Ubuntu) or browser, print correctly onto pages (at the right DPI for images for example, over 72dpi), scale to work for those with vision needs/screen resolution/device…


    not have to rewrite/change/tweak/etc the content?

    And be hyper linked together so one document can be related to another. 

    I have found that using table-less valid strict XHTML code and CSS for style while basing most (if not all) things on em makes the cross platform – cross browser challenge fairly do-able.

    I was inspired towards this back in the CSSzenGARDEN days.
    Thanks to all you designers that made that site rock!

    But then there is printing and portable devices and better accessibility.

    One only lives so long. How many times do we really want to recreate the same document/content for a new device, browser, printer, email or software just because a decade has passed
    or MS has some new notion of how to keep people locked into THEIR closed source
    As artists, do you not want to create new art instead dredging through old documents and recreating old documents to work with current technology?

    A paper page is the size a paper page which is fixed and yet not as and now we have many countries and thus pages sizes.

    What is the best approach for the long run?

    There is much ado about creating web page/site that work for what ever is current and happening in the now like a fluid 3 column lay-out but
    I am asking/questioning/yearning about content.

    Even the content I write at this moment is UNUSABLE again with out tweaking because it is coded to Textile which seems to only be some what working and is not XHTML

    Copy & paste the code below to embed this comment.
  23. Seems like the CSSzenGARDEN site slowed way down for a while and they look like they are going strong. : )

    The A List apart is an A list site for sure. Thanks again…

    Copy & paste the code below to embed this comment.
  24. Table cells with multiple lines break the rhythm of the complex example. I checked it using the “background image”:/d/settingtypeontheweb/images/gridbg.gif

    Copy & paste the code below to embed this comment.
  25. There’s also a easy trick for this one:

    An em is 16px.
    10px equals 62.5% of 16px, or an em.
    So if you put the font-size for the body element to 62.5%, it’s easy to calculate the other ones.
    E.g. if you want 12px font-size, you just put in 1.2em. Because 1.2 * 10 = 12.


    Copy & paste the code below to embed this comment.
  26. Generally, I love ALA’s typesetting, and this article was good. However, when I went to the complex example, I noted something that from the standpoint of readability is just plain wrong: The same amount of vertical space before and after heads, esp. subheads. As a reader, you need visual cues to connect a [sub]head to the text it is heading; therefore, there should be visibly more space ABOVE the head than below it. Not to pick specifically on this writer—I see this all over the web.

    Copy & paste the code below to embed this comment.
  27. A very informative article, however…
    When it comes to CSS, positioning containers is the real pain. Choosing some lovely font sizes and colours is a nice gentle way to finish off an otherwise stressfull afternoon of building a CSS website.

    Copy & paste the code below to embed this comment.
  28. There are two properties that allow you to automatically set the capitalisation of your text. First, font-variant allows you to set all your characters in small versions of capital letters.

    p {font-variant: small-caps; }

    That would create text like this. It looks cool, and works well for acronyms, like NATO. The second property is text-transform.

    div {text-transform: uppercase; }

    Copy & paste the code below to embed this comment.
  29. Can someone please explain why, in the “complex example”, the multiplier is usually 16, 14, or 12, and in one instance it is 18?

    font-size: 1.125em; /* 16×1.125=18px */

    margin: 1.286em 0; /* 14×1.286=18px */

    border-bottom:0.083em solid #ccc; /* 12×0.083=1px */

    margin:1em 0; /* 18×1=18px */


    Thank you

    Copy & paste the code below to embed this comment.
  30. I’ve used the principles in this article as my best-practices for years. However, my company just stopped supporting IE6 last year and we are now revisiting our best practices for sizing text. Since most browsers now use page zooming, we’ve considered switching to pixels to size our text, but our new concern is mobile browsers. How well do mobile browsers handle different units? Which unit is best to use with mobile browsers in mind? I’ve heard many say that Ems are still the best practice for mobile devices, but I’ve noticed that iPhone 4 doesn’t seem to size the complex example from this article correctly. Is it better to use pixels for mobile?

    Copy & paste the code below to embed this comment.
  31. Most of the wordpress themes that I have encountered do have a widget or plugin to allow visitors to change the text size, as it is sometimes too small from default, and messing with the CSS can be a pain at times.

    Copy & paste the code below to embed this comment.
  32. Thank you for the article and your effort.

    I just thought I would offer comments now that it is almost 4 years old, and surely out of date. It seems like this article advocates acrobatics of web design with ems, percentages etc, when, to me, if you can’t read something you magnify it with glasses or the equivalent, zoom, on your browser. Magnifying the text and images (line height etc) keeps their context and their visual relationship constant – a good thing. advocating the ability to resize the text while keeping other things like images constant is a misguided idea because when increasing text size eventually the relationship of text to images gets uglier and nonsensical. If there is a need to magnify text, wouldn’t it also help a visually impaired type to magnify the images, too – bring them into focus?

    In addition, I agree with the unpopular Brad Kemper – good typographic practice is to add less than a line between paragraphs – I prefer 1/2 a line. I am not a coder giving my typographic opinion, but someone who has lived and breathed typography for many years and has been recognized for skill in typography. I am not too familiar with the author’s concept of vertical rhythm, but vertical rhythm should not be slavishly adhering to a baseline grid – that would be a monotonous rhythm – not to interesting and rather mechanical.

    Copy & paste the code below to embed this comment.
  33. I’m with Josiah in that I too, am curious which unit is best to use with mobile browsers in mind?

    It would be nice to get an update to this article with mobile devices in mind. I’d be curious if EMs are still the best solution, or if something like REMs with an appropriate fallback or pixels is preferred now. Pixels seemed to have gain a lot of popularity for sizing fonts.

    I know in jQuery Mobile they use pixels for font sizes and also in the HTML5 Mobile Boilerplate:

    body { margin: 0; font-size: 13px; line-height: 1.231; }

    Yet knowing a pixel is no longer a pixel on some new devices like the iPhone4, it makes me think pixels aren’t the correct solution to sizing fonts on these newer mobile devices where the pixel ratio isn’t 1:1. I havn’t done any testing on font-sizing on mobiles yet but I would think EMs or REMs with an appropriate fallback will be the best solution for mobile?

    Copy & paste the code below to embed this comment.
  34. Just picked up an old book of mine called Bulletproof Web Design. It suggests setting the body font size as a Keyword…. small… and percentages to stray form the base. eg h1, 150%

    This seems rather a good idea than having all that crazy em mathematics. What do you guys think?

    Copy & paste the code below to embed this comment.
  35. If this is ever updated please include more sample calculations. Font size ems seems to be easy to figure out, but the line heights – especially when the font is larger than 18 pixels is giving me a headache LOL. Similar to @lauras2009 question above.

    It’s also not clear to me why this was updated away from the 62.5% rule, when that kicked out such lovely round numbers and made the maths so much easier.

    Copy & paste the code below to embed this comment.
  36. Richard thank you for presenting this info so clearly. This is another element in a developer’s bag of tricks to help create responsive web design.

    Copy & paste the code below to embed this comment.