Elliot Jay Stocks is a designer, speaker, and author. He is the Creative Director of Adobe Typekit, the founder of typography magazine 8 Faces, one half of Viewport Industries, and an electronic musician.

Choose your web fonts wisely

Posted on 01 September 2011 19 comments

Article illustration for Choose your web fonts wisely

I’ve lost track of how many times I’ve used the phrase, ‘right now is an exciting time for type on the web,‘ but amidst all this excitement, let’s not forget that there are some very important considerations we need to bear in mind when selecting all these lovely new typefaces for our projects.

I don’t think I’ve ever done as much rigorous typeface comparison as I’m doing right now for the Smashing Magazine redesign and, as I tweeted the other day,

I’ve just been reminded of a very important lesson that I occasionally forget: test web fonts on Windows, because a lot of them look shit.

~ me

It’s something we can all easily forget when we get wrapped up in having multiple typeface choices available to us, but it’s a huge consideration.

The slightly more daunting prospect is that it’s not simply a case of good or bad; there are several variables at play when you break the consideration down into its component parts. Here are some of the main ones, listed loosely in order of the production line (i.e.: from original typeface design through to the end user’s experience of the font):

  1. How suitable is the design of the typeface?
  2. How well is the font hinted?
  3. From which font delivery service is it being served?
  4. What font size is being used?
  5. On what system configuration is it being viewed?

How suitable is the design of the typeface?

This is a somewhat arbitrary concept and one you could quite literally write a book about, but I’ll mention it here briefly because it’s a personal decision that does also have knock-on technical considerations. As a very rough generalisation, the more intricate the details in a typeface, the less suitable it will be for body type. You could therefore have the most excellently hinted font in the world, but used in the wrong context, it could still look terrible. So, in the first instance, the web designer has the responsibility of choosing the appropriate typeface for the job before further technical considerations come into play.

I think that’s all we need to say about that.

How well is the font hinted?

Font hinting is a bit of a dark art, and something many of us choose to gloss over. Don’t, though, because even a loose understanding will help explain the way type is displayed on screen, particularly on Windows.

Essentially, ‘hinting’ is the act of inserting TrueType instructions into a font file, which are needed for Windows rendering engines to appropriately fit the font to the pixel grid. If you’ll forgive my shameless plug, Tim Brown wrote an excellent article about Type Rendering and Web Fonts for our latest issue of 8 Faces, in which he said:

TrueType instructions are an expensive, time-consuming effort that requires specific knowledge, patience, and technical and aesthetic aptitudes. Web fonts that have TrueType instructions tend to look very good on Windows; those without often do not.

~ Tim Brown

As Tim mentions in the article, individually hinting every web font that becomes available is something of a pipe dream, but there is hope: Microsoft’s new rendering engine DirectWrite (a successor to ClearType) brings OS X-like type rendering to Windows and is used in IE9 and available as a preference in Firefox 4+.

An alternative to using TrueType instructions is to use PostScript instructions instead, which often work better on display typefaces for those users who have yet to update to a DirectWrite-capable browser.

For a more thorough look at type rendering, be sure to read through the excellent articles posted on the Typekit blog. I’d also encourage you to read this slightly older article by my studio mate Jon Tan. I know Jon has been doing a lot of detailed research into the current type rendering landscape recently, and I’m hoping that my mention of it here will bully him into writing a new post!

From which font delivery service is it being served?

When a typeface and its fonts are listed on multiple font delivery services (Typekit, Fontdeck, Google Web Fonts, webfonts.fonts.com, WebINK, et al), you could be forgiven for assuming that the fonts served will be identical and, when viewed on a Mac, that might seem the case. However, viewed on a PC browser without the DirectWrite rendering engine and without the enhancements mentioned above, the differences become startlingly apparent. In fact, even if the enhancements mentioned above are in use, the difference can be obvious: what if one font delivery network serves a font file that employs PostScript instructions and another does not?

Consider LFT Etica, by Type Together, which, for a while, we were testing as the body face for the Smashing Magazine redesign. On a Mac, versions served by Typekit and Fontdeck look virtually identical (for the purpose of this demonstration, let’s limit ourselves to just two services), but examine them on a PC and you’ll see some noticeable differences.

Look at the lowercase ‘w’. Served via Fontdeck, the apex of its middle strokes falls shorter than the x-height and could be considered a little strange, especially since it’s not true to the original design. Overall, though, the type feels a little more crisp than the Typekit version.

Screenshot showing comparisons between Typekit and Fontdeck

Fig. 1: Screenshot taken using Chrome on Windows 7, with ClearType enabled.

So which version do we choose? Both have their pros and cons; ultimately, it comes down to the designer’s preference for what is most appropriate overall for the task at hand.

What font size is being used?

At larger sizes, the opposite of our body example is true: Typekit’s version of LFT Etica Extra Bold does a better job of anti-aliasing the outlines when compared to Fontdeck’s version. It looks like they’re using PostScript outlines here to achieve this, especially as zooming in on the screenshot reveals greyscale (bi-directional) anti-aliasing.

Screenshot showing comparisons between Typekit and Fontdeck

Fig. 2: As before, screenshot taken using Chrome on Windows 7, with ClearType enabled.

So again we must ask ourselves: which version do we choose? And again we must conclude that it comes down to the designer’s preference for what is most appropriate overall for the task at hand. There is no ‘right’ answer.

On what system configuration is it being viewed?

We’ve been talking about it throughout the entirety of this post, but technically the actual system configuration of the individual user is the last stage in the process of the ‘type experience’: the designer’s choice of typeface, the quality of the original font file, the version being served via a delivery network, and the size(s) at which the font is rendered are all, ultimately, at the mercy of the user’s personal set-up.

Every single one of the stages prior to this forms part of a fail-safe plan to get type looking as good as it possibly can, but sadly we just can’t predict…

  • the operating system;
  • the browser;
  • the browser’s rendering engine (which can be limited by the underlying operating system);
  • the screen size, type, and resolution;
  • the power of the computer;
  • the environment in which it’s being used (think desktop in an office versus mobile phone in direct sunlight);
  • and numerous, personal, user-controlled system preferences and browser preferences.

In the face of such adversity, the temptation is to give up and / or ignore all of these considerations. But don’t, because font files get tweaked, companies optimise their services, browsers improve their rendering, and technology — and users — get smarter.

And that is why it’s so exciting to be working with type on the web.

(I hope the above was helpful. In the next post in this series, I’ll be looking at how I’ve been taking a ‘type outwards’ approach to the Smashing Magazine redesign.)


  1. Anders Drage

    Anders Drage

    01 September 2011 @ 11:42AM #

    Great read! looking forward to the next one :)

  2. Marco Slooten

    Marco Slooten

    01 September 2011 @ 11:58AM #

    Very nice post! I’ve encountered the mentioned Windows font-rendering issues while redesigning my website. It’s something that very easily gets overlooked, but in reality, the majority of the website visitors will probably be on Windows, so it’s very important.

    So naturally, I’m also very excited about webfonts getting better. It’s a shame to have to use Helvetica/Arial on every website.

  3. Jon White

    Jon White

    01 September 2011 @ 12:17PM #

    Excellent post, Elliot! I’m wondering: can one soundly mitigate issue #3 (discrepancies between font-delivery services) by — if the font’s EULA allows it — hosting it locally to one’s own site? Or do the local-kit-compilers (like, say, FontSquirrel’s) not provide enough fine-tuned options to enforce necessary across-the-board quality? (Me, I’m biased toward the “keep ’em local” method just due to ease of local development. But I’m also lazy.)

  4. Phil Middlemass

    Phil Middlemass

    01 September 2011 @ 12:51PM #

    Great write up and something I have come across a number of times. There seems to be too much fragmentation of font rendering on Windows. Too many variables to consider in the possible outcome; ClearType/Standard/DirectWrite + what the browser itself will do, I’ve even ClearType rendering between IE7-9/Chrome/Firefox to show slightly differing results.

    I’ve also come across some strange issues in Chrome(windows) using WebFonts output through FontSquirrel where they appear to have a faux bold effect and I can’t seem to find a way to remove it.

    There is also the WebKit hack to consider for Chrome/Safari on Windows by applying a hidden CSS effect such as text-shadow: 1px 0 0 rgba(0,0,0,0.01) (there are a few others) you can force those browsers to use a smoother anti-aliasing method

  5. Stewart


    01 September 2011 @ 12:59PM #

    Interesting read Elliot. Just wondering what your thoughts are on embedding fonts via Cufón or is that a big no no due to the less than clear legal situation?

  6. tymc


    01 September 2011 @ 01:19PM #

    As Phil Middlemasssays, you can use a CSS 3 hack to smooth big fonts.
    You can take a look here : http://dribbble.com/shots/186801-Smoothing-webfont-using-CSS3

  7. Tom


    01 September 2011 @ 03:56PM #

    Good read as always Elliot. One resource I’ve found particularly useful over the last few years is the Codestyle font survey – http://www.codestyle.org/css/font-family/sampler-CombinedResults.shtml. Obviously, this is becoming less relevant with the quality of font hosting services nowadays but it’s still useful if not using font hosting or for assessing fallback options.

    @Stewart Cufon, like sIFR, should really be consigned to the scrapheap now – there’s no real need for it any longer. Aside from the legal issues, it is a pretty inaccessible solution as a user can’t select the text properly and it requires Javascript. The only time I can think that Cufon or sIFR could be used would be if you MUST use a particular font that cannot for whatever reason be hosted. I would think this to be a fairly unusual situation as a font would most likely be on one of the many font hosting services or you could create a @font-face pack at Font Squirrel, for example.

  8. Stewart


    01 September 2011 @ 05:37PM #

    Nice post, like the comment about fonts looking shit on pc’s

  9. Steinar Hovland

    Steinar Hovland

    01 September 2011 @ 09:04PM #

    Thanks for this excellent writeup on webfonts. I’ve experimented with alot of font-services on clientwork, but alot of the time its been voted against before launch. Mainly because of the poor support on Windows. Atleast this will give me a better fighting chance!

  10. bwigen


    02 September 2011 @ 05:34AM #

    Thanks for the post. I just spent a few extra hours fixing this very same issue on a site I was collaborating on.

  11. Jason Hunt

    Jason Hunt

    02 September 2011 @ 09:52AM #

    Great post. The devil is, as they say, in the detail… The term ‘web-safe font’ has a whole new (more complex) meaning! At least things are getting better.

  12. Keith


    03 September 2011 @ 03:47PM #

    Thanks for the very informative article (and thanks to tmyc for the link).

    One thing that jumped out for me, though, was your statement that testing web fonts on Windows is “something we can all easily forget.” The assumption here seems to be that web design and development is purely a non-Windows (a.k.a. Mac) profession. This is not the case, of course. Some of us are in positions that require/force the use of Windows machines, and testing on other platforms is something that gets shoved into a dark corner.

    I agree, however, that web font rendering across different platforms, environments and endpoints is sometimes discouragingly inconsistent (heck, even on a single Windows machine you can get the worst inconsistency from browser to browser). I appreciate your reassurance that we shouldn’t simply abandon hope or curtail our efforts in the face of so many factors.

  13. Davide


    07 September 2011 @ 01:17PM #

    I never thought how important fonts can be. Thank you for bring up such an important issue!

  14. Chris


    07 September 2011 @ 03:23PM #

    It is a big frustration, the massive variability of font display across various browsers on Windows.

    Weirdly, I tend to get better web font smoothing in Firefox over Chrome, but the aliasing on the actual text within the program, on tabs etc, is so much worse that I still prefer Chrome for text overall!

  15. Hawaii Web Design

    Hawaii Web Design

    08 September 2011 @ 09:56PM #

    this nailed it “I’ve just been reminded of a very important lesson that I occasionally forget: test web fonts on Windows, because a lot of them look shi”

    It sucks that windows and internet explorer have such large market share and everything looks crappy on it… I could only wish apple would lower its price and more people got better computer and software…

  16. mattyk


    09 September 2011 @ 09:31AM #

    Very helpful! thanks. I actually work mainly on a windows machine as many of my clients are windows based. In a way, I’m lucky – if it looks good on my machine it looks great everywhere else.

    One thing I’ve yet to find is a definitive place where you can search for a fonts licence and whether @font-face is allowed (that isn’t a font service). I’d love to see that as I spend hours trawling through legalise trying to work this out. Then I look at the rendering just to find it looks awful. Maybe I should just bite the bullet and stick to a font service!

  17. Greg


    10 September 2011 @ 02:13AM #

    It’s true that fonts render like crap (most of the time) and more inconsistently (all of the time) on Windows. I had an interesting discussion with another web dev on the subject and during that discussion we actually identified times when the Mac underperformed (he was very pro-Mac and I was trying to show that there’s hope for Windows).

    It’s the inconsistency that’s the problem, though. It’s a fact of improving something: the newer rendering technology will look better, and the hordes of people with older tech will see nothing but “yuk”. That doesn’t change what a highly variable situation we face, but I don’t think it’s fair to draw a comparison between an operating system that’s the latest (who out there is using OSX older than 10.5?) and one that’s not (Windows XP with IE7 for example).

    Here’s my understanding from when I last researched; the caveat is that I didn’t re-do my research just for this comment, so make sure you don’t just take my word (or anyone else’s for that matter) without confirming for yourself:

    OSX is consistent because for the web at least it universally employs bi-directional full-pixel anti-aliasing (the grayscale stuff). Windows ClearType and DirecType use sub-pixel rendering. The former is consistent and reliable, the latter has the potential to not quite work out (as we’ve all seen) but far more potential for accurate and beautiful rendering.

    I would choose OSX’s method any day of the week as of right now. It simply looks better more often.

    But I think it would be a mistake for readers to just blindly jump on the “Mac is better, Windows sucks” kick without actually knowing WHY they feel that way.

  18. Matt Hinchliffe

    Matt Hinchliffe

    12 September 2011 @ 10:47AM #

    One of the first little changes I made at my current job was to create a very basic test suite for checking font readability before sending designs to a client. Of course I had worked on projects previously where this wasn’t tested and clients demanded font-replacement techniques as it appeared better on their screens (these are very clever but without exception; shit).

    We now check fonts on an XP VM with and without Cleartype (or even in Safari sub-pixel rendering) and choose the most readable sizes to avoid issues when using non-TrueType fonts.

    The source can be found here: https://github.com/i-like-robots/Snippets/tree/master/Font%20Face%20Test

  19. charlie


    12 September 2011 @ 03:40PM #

    Another good reason to utilise current Google analytics stats of a site before redesigning.

    You can quite easily see what the important browsers/OS/screen size are for each clients visitors.

© 2005 – 2014 Elliot Jay Stocks. All rights reserved. Powered by Harmony and tracked by Gaug.es. To keep updated with new content, you might like to subscribe to my RSS feed.