A short history of body copy sizes on the Web

It’s hard to pick a font size that is just right, especially as you try to adapt to different screens and scenarios. Looking at the recent history of how we got here can give us some perspective.

When I started working on Web stuff around 2005, there were two extremely popular font styles for body copy:

• 10px Verdana;
• 11px Arial.

Those two styles appeared on maybe 90 percent of professionally built sites, to be seen by users on IE5, IE5.5 and IE6 on Windows XP and earlier versions. They also looked similar, thanks to heavy font hinting, lack of font smoothing or sub-pixel rendering, and the fact that Verdana has a bigger x-height so 10px Verdana was roughly equal to 11px Arial, only with slightly wider letters.

Ten and 11 pixels may seem puny today, but in the early 2000s that was deemed readable for two reasons:

1. the 800×600 and 1024×768 screens of the late 1990s and early 2000s had biggish pixels, so the result was on the small side but not as small as it might look today;
2. designers and their clients were accustomed to 9, 10 and 11 point sizes for body copy in print (books, magazines, leaflets…), and the prospect of using bigger values felt like shouting at readers.

With relatively little experience of the Web as an autonomous medium, graphic designers and marketing departments relied on previous knowledge — from e.g. QuarkXPress and Microsoft Word. “How do I translate this point size, which works in my leaflet or magazine ad, to a HTML size?”

Of course, there is no way to reliably translate typographic points to pixels, because pixels don’t have a universal physical size. Screens have different pixel-per-inch ratios. The original Macintosh had a 72ppi screen (or perhaps 68ppi?¹). Twenty years later, in 2004, screens in the 80–90ppi range were common. A few years laters, pixels had gotten a bit smaller, and screens were often in the 90–120ppi range, while most iPhones had a 160ppi resolution². Despite the popular misconception, and even before the Retina transition started, the Web’s resolution was not 72ppi; it never was a single thing.

However, we don’t need to work out the exact points-per-inch resolution of every device to make sensible design choices. Trying things out should always trump dpi, ppi, Retina, or even pixel counts.

In November 2006, iA’s Oliver Reichenstein ran a simple experiment: he compared a magazine’s body copy at arms’ length and a typical site’s body copy at a common, eye-to-desktop-screen distance. The website’s text looked much smaller. Oliver argued for setting the body copy to the browser’s default, or 100%, which by convention is 16px in common browsers. In 2006, and even a few years later, it was a revolutionary proposition. Web designers and clients thought it was extreme. Five years later, we still had to fight for the death of 11px body copy (example, in French).

Text that is too small takes more time to read. Users may have to lean towards the screen, hold mobile devices closer, squint, or just concentrate more. As designers and developers, we strive to not ask for such extra effort from people who use or read our work.

On average, online text got bigger — at least in nominal pixel sizes — in the late 2000s and early 2010s. The exact reasons why are anyone’s guess, so here’s mine:

• the medium’s matured, thanks to arguments such as the one spelled out by Oliver Reichenstein;
• text in the 10–12px range looked tiny on the iPhone and other early smartphones (resolutions in the 150–200ppi range).

I remember web designers and developers leading the way with blogs, professional news sites and the occasional client project set in “bigger” sizes in the 14–18px range. This evolution seeped into generalist news sites, one high-profile redesign after the other; nowadays, theguardian.com has 1.0625rem (17px) text with 1.5 line-height, nytimes.com used 17px font-size and 26px line-height circa 2017, and in 2019 it went up to 20px font-size and 30px line-height on wide screens; body copy in the 18–21 pixel range is common (Medium, bostonglobe.com, newyorker.com, liberation.fr…).

Those numbers only mark a point in time. Back in 2003, 12px Arial might have been a generously big, very readable option for that majority of users on 800×600 screens with font smoothing turned off. The feeling that the browser’s default font-size was too big, which was very present when Oliver’s article was published in 2006, was partly a cultural thing, but it had some technical reasons as well. Likewise, we’ve started to feel that 16px is rather small for all but the smaller screens, again for a combination of reasons.

Then there is the very big body copy trend. In April 2012, influential web designer Jeffrey Zeldman redesigned his site with 24px Georgia body copy (and 32px for the opening paragraph of each post). Many fellow designers were puzzled, and some complained that the design was hard to read or reported having to zoom out on laptops or desktop computers to be able to read comfortably. Still, that design lasts today. Other designers have used similar sizes, e.g. Trent Walton stated his preference for 20–24px text (or 125–150%).

The most recent example of that trend is Jeremy Keith’s Resilient Web Design online book. Jeremy uses a CSS lock³ to vary the font size depending on viewport width, between two boundaries: 100% and 250%. At 320px, you get (with default browser settings) a 16px font size. At 1600px, you get 40px text. Obviously this is a design choice, and I recon that — similar to what Trent Walton described — the intended effect for laptop and desktop use is that readers lean back and read with their faces away from the screen rather than leaning towards it. It’s a design that invites taking your time instead of skimming through the text.

While that design makes for a good reading experience on smaller screens (especially smartphones and tablets, in my tests), I find it difficult on larger screens. The main issues I have with it are:

1. Seeing very few lines of text at a time. For instance, 10 lines of text on a 13 inch laptop. I have some level of attention deficiency when reading, and this setup removes a lot of visual context when I try to scroll and read; I generally try to fight the attention deficiency by selecting every other paragraph I’m reading, but when the design only shows one or two paragraphs at a time, that doesn’t help.

2. Each line of text is physically wide, requiring the reader’s eyes to span a wider angle than usual. This could have two undesired effects: readers might end up doing more fixations to read the same line of text (e.g. 3–5 instead of 2–4); and in more extreme examples, the wider eye movements could cause eye strain or fatigue.

Let’s say someone is seating in a sofa with a laptop on their lap, and currently reading an article. And let’s suppose that for this person in this setting with their own preferences and current level of fatigue etc., there exists an ideal font size for reading whatever text they’re reading. For instance, it could be 22px.

The reading process involves saccades and fixations. On each fixation (which can span a quarter of a second), they are only seeing a small portion of text in focus:

Now if the same text was quite bigger, but the other parameters (like the eye–screen distance) didn’t change, I’m guessing the result would look like this:

With the focus area staying the same size, and bigger text, I suspect that the eye can discern fewer letters correctly on each fixation. This is why my hypothesis is that for really big text (like Resilient Web Design’s 250% body copy on wider screens), readers will need to use more eye fixations to read the same text, and might lose in reading speed and experience fatigue sooner. I don’t have the skills needed to test this hypothesis, but I’d be wary of the very big text trend.

Personally, I favor more limited tweaks in font size. I like starting with a 100% basis for small screens, bump it for large phones or tablets (say, 110% or 115%), and maybe go up to 125% on laptops and larger screens. Then I tweak those values depending on the font I’m using, the look I’m going for, and what I’ve seen in testing on a variety of devices.

I’m also sad that we’re somehow chasing after device makers, operating system and browser developers, and trying to tweak font sizes every other year to adapt to what is out there in the market. The very concept of raising font size a bit depending on the screen width should raise eyebrows. Isn’t it the device’s job to make sure that font-size: 100% is readable?

In theory, CSS pixels should match a “reference pixel” defined as an angle of vision:

The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch).

But this rule can only be followed if hardware makers, operating system and browser developers all collaborate towards that goal, which is rare enough. Especially since hardware vendors are more interested in selling screens optimized for video resolutions (“1080p”, “4K”), even when it makes the whole UI awkwardly small.

In theory again, browser makers should be able to change the 16px default font size to adapt to modern devices. But too much existing content relies on this default size not ever changing.

And so, we guess; we test; we tweak.