Selecting a beautiful typeface is useless if it looks ugly on your screen. To avoid hideous – or worse – illegible text, you should always test if the font works well on the devices your visitors are using. You might be surprised; most of your visitors are probably not using the same device you use to design and develop. In fact, the vast majority of people surfing the internet are using Android and Windows machines.
The best way to test how a font behaves is to set a sample text in the font and try it out on all devices that you target. Bad rendering is especially noticeable on thin weights.
For example, a font that renders well on macOS may appear fragile on Windows (see image below). It’s important to use real devices, because online browser-testing tools and virtual machines are often inaccurate (more on that later).
If you don’t have your site’s content yet (tsk!), give Tim Brown’s Web Font Specimen a spin. It sets content at several text sizes and with different background colours. It’s no replacement for real content, but it’ll do in a pinch.
Sometimes you get lucky, and the font you have chosen is designed explicitly for screens: Hoefler & Co’s ScreenSmart, Monotype’s eText, and Font Bureau’s Reading Edge are examples of collections specifically designed with screens in mind and should look beautiful everywhere. Of course, it pays to double-check the text rendering, regardless of the origins of the font.
But exactly why does text look different from one browser to the next? To answer that question, we’re going to have to take a quick detour into the nitty gritty details of text rendering.
Rasterizing and antialiasing
The process of transforming font outlines into pixels is called rasterization. The operating system’s text-rendering engine places the outline (ie the shape) of each character at the desired font size on a pixel grid. Next, it colours all the pixels whose centre is inside the outline (see image below).
In this example, a pixel is either on or off, no matter how much of the outline is present in the pixel. This approximation of mathematically perfect outlines is called aliasing; antialiasing attempts to mitigate the coarse staircase-like appearances caused by the limited resolution of screens.
The idea behind antialiasing is to figure out how much of the outline is present in each pixel and represent that with a greyscale value. In other words, if the outline covers 50 per cent of a pixel, it uses 50 per cent of black to colour that pixel. If the pixel is entirely within the outline, 100 per cent black is used, and so on. This leads to an antialiased rendering that reduces the aliasing (see image below). You’ll often see the term ‘greyscale antialiasing’ used to describe this effect.
While antialiasing improves the quality of text rendering, it’s possible to improve the result further using subpixel antialiasing. Subpixel antialiasing makes use of the characteristics of screens to increase the resolution of rasterized text. Each pixel in a display is made up of three oblong subpixels: red, green, and blue (other configurations exist, but the same principles apply). The operating system can control these subpixels individually; subpixel antialiasing exploits that by applying the coverage calculation to each subpixel (see image below).
The difference between these text-rendering options becomes evident when you start working at smaller text sizes. Without antialiasing, characters quickly lose their distinctive outlines. Greyscale antialiasing makes characters blurry but maintains their shape. Subpixel antialiasing renders sharp characters but also introduces some colour fringing around the character’s edges.
Antialiasing tips
You can change antialiasing settings through the non-standard -webkit-font-smoothing and -moz-osx-font-smoothing CSS properties. Unfortunately, many CSS frameworks and libraries use the antialiased and grayscale values to make the text appear lighter on macOS. However, most developers and designers don’t realise this disables subpixel antialiasing and makes text appear blurrier, thereby hurting legibility.
Changing someone else’s preferred text rendering to be less legible is very inconsiderate. If you must have lighter text, use a lighter weight instead of disabling subpixel rendering.
Text-rendering engines
Most operating systems use their own proprietary text-rendering engine, while others use the same open-source engine (though not necessarily with the same configuration). However, all of them support antialiasing and subpixel antialiasing but differ slightly in their implementation. In many operating systems, the choice of antialiasing method is user-selectable. On Windows, for example, subpixel antialiasing is called ClearType; on macOS, it is called LCD Font Smoothing.
There are currently four major text-rendering engines: the Graphics Device Interface (also known as GDI) and DirectWrite on Windows; Core Graphics on macOS and iOS; and the open-source FreeType on Linux, Chrome OS, and Android.
Generally speaking, a browser will use the text-rendering engine that’s native to the operating system it is running on. Chrome, for example, uses DirectWrite on Windows, Core Graphics on macOS, and FreeType on Android. Windows is unique in that it offers two text rendering engines: GDI and the newer DirectWrite.
All modern browsers use DirectWrite, so you don’t need to worry about GDI save for one exception: some browsers fall back on the inferior GDI rendering if the machine has no dedicated graphics hardware. Online browser-testing tools and virtual machines often do not have dedicated graphics hardware, so text-rendering on these tools is not accurate.
Ideally, all text is rendered using subpixel antialiasing because it creates the most legible text. Unfortunately, that is not always possible – for example, subpixel antialiasing is often disabled on devices that can be rotated, such as tablets and phones. When you turn the screen of these devices, the subpixels are no longer arranged in the pattern expected by the rasterizer and will cause subpixel antialiasing to look ugly.
Browsers also disable subpixel antialiasing in similar situations, for example when text is rotated or animated. In this case, the rasterized text no longer matches the subpixel layout of the text’s original position and would need to be rasterized again. This is expensive, especially for animations, so most browsers fall back on greyscale antialiasing, which doesn’t suffer from the same problem and works in any orientation.
Some browsers – Chrome on macOS, for instance – also disable subpixel antialiasing on high-resolution screens to provide a more consistent user experience. Other browsers only enable subpixel antialiasing on small text, because minor changes in text rendering are less visible at larger sizes.
There are several other cases where browsers disable subpixel antialiasing. The rules browsers use to select the antialiasing method are constantly updated as new corner cases, and problems, are found. These frequent changes make it very hard to keep track of what is going on with your text rendering. What once used subpixel antialiasing may fall back to greyscale with the next browser update. The only way to know for sure how your text renders is to test on actual devices.
You’re probably used to testing your site in several browsers. Testing text rendering increases the amount of testing you need to do manifold. Not only do you need to check all combinations of operating systems and browsers, but also all common text rendering settings.
Some devices may be preconfigured to use greyscale antialiasing while others use a mix of greyscale and subpixel antialiasing. To make it even harder, it is not possible to use online-browser testing tools or virtual machines, because the text rendering often differs from that of real devices.
When testing, always use a representative sample of your content. A pattern library is ideally suited for testing type rendering because it includes a broad sample of your content: headers, body text, labels, background colours, and animation. Having examples of your content on a single page enables you to check all combinations of styles and background colours quickly.
Be on the lookout for text that is not legible or appears thin on some operating systems. If you find an issue, change to a different weight in the same font family, make the text darker, or pick a different typeface. Good luck.
This article was originally published in issue 301 of net, the world's best-selling magazine for web designers and developers. Buy issue 301 or subscribe to net.
Related articles:
