Why some fonts suck on Windows? Rendering and “hinting”


“Why does the same font on screen look fine on the Mac but like cr*p on Windows?” “How can I get fonts to look good cross-platform?” These are a couple of the most common questions I get about web fonts, which all have the same explanation. The short explanation: it’s an interaction between the fonts and the OS-level rendering. For the long explanation, keep on reading, and see the many screen shots at the bottom of the page.

Today, fonts display differently on the various platforms, but this wasn’t always the case. There was a time, for most of the 90s, when the same code was used to render fonts on Mac and Windows. Both platforms did aliased jaggy type when the font said to do so, and switched to anti-aliased grayscale type at the sizes the font told them to. On Windows, this was GDI grayscale rendering, the default rendering on Windows XP. You can still get this on Windows Vista or Windows 7, in most applications, by turning off ClearType (Control Panels > Display > Adjust ClearType Text).

Microsoft improved their GDI text rendering with a technology called “ClearType.” It’s optional in XP, and on by default in Vista and Windows 7, plus Internet Explorer 7 and up will turn it on for you. IE9 has switched to an even better rendering system, the DirectWrite version of ClearType. This is all very well, but between Microsoft Windows with their ClearType rendering and Mac OS X with Quartz (mostly inescapable, though you can tweak a preference to turn it off for small sizes), we now have different rendering approaches on different platforms. (I’m not even going to get into Linux text rendering, which uses a different rendering system entirely, usually FreeType.)

Okay, so they’re different. But why do we get the results we do with custom web fonts, where sometimes a font looks just fine on Mac OS but looks awful on Windows? To answer that, more background is needed.

Three key concepts you need to know about font rendering are “anti-aliasing,” “sub-pixel rendering,” and “hinting.”

  • Anti-aliasing — Filling in diagonal or curved edges with shaded pixels to achieve a smoother appearance.
  • Sub-pixel rendering — Turning on part of a pixel instead of an entire pixel. It’s most interesting when dealing with LCD displays, where each pixel is comprised of three vertical sub-pixels (red, green and blue), so you can turn on or off just one or two sub-pixels at the edge of a line to achieve effectively greater horizontal resolution. ClearType does this kind of LCD-optimized sub-pixel rendering.
  • Hinting — Additional code in a font that improves its appearance at typical screen sizes, at least for rendering that cares about hinting (such as Windows). The code can be created manually or generated automatically, or sometimes in between. Full-on manual hinting is a lot of additional work, so is usually reserved for


The basic difference in the rendering approaches is this: Apple uses a softer and fuzzier approach to anti-aliasing, which does a better job of preserving the general appearance of letters, but at the cost of crispness. At any size you normally see, they also throw out the hinting of the original font and replace it with their own on-the-fly auto-hinting. So Mac and iOS rendering is much less sensitive to this aspect of font production quality.

Microsoft, on the other hand, does crisper rendering and relies on the hinting in the font to help the rendering engine get good results (though with ClearType on, the horizontal-direction hinting is less relevant). The result is that at small to middling sizes, a lot of fonts end up looking pretty bad on Windows.

Microsoft has continually improved their rendering, but as of this writing, the only browser using the state-of-the-art DirectWrite ClearType is IE9. The older versions of ClearType made an “interesting” trade-off: while they give effectively better horizontal resolution, they don’t do anti-aliasing at all in the vertical direction, only horizontally. This leads to people sometimes thinking of ClearType text as “jaggy” when it comes to diagonals and nearly-horizontal parts of curves. Some people even resort to a variety of tricks to get grayscale rendering instead of ClearType at really large font sizes.

Although intelligent design of the letter shapes can optimize fonts more for screen, it doesn’t make up for the lack of carefully hand-tuned font hinting code.

So the net effect is this: perfectly hinted fonts look great at all sizes in Windows browsers and apps. But the big mass of fonts out there, even most being made available as web fonts, have only automatically generated hinting code in them, and have some pixel size below which they will start to look like poop due to undesirable shapes, counters filling in, lack of space between glyphs, or all of the above.

To make it worse, what that minimum size is generally depends on which rendering you’re looking at. Whether or not you care about folks running old XP systems is, of course, up to you. Generally grayscale rendering (ClearType off, XP default) is worse at smaller sizes, but at least it has anti-aliasing in both vertical and horizontal directions. Indeed, nightly builds of Chrome 17 currently use ClearType at small sizes, and turn it off above 48 px, because they think it looks better. I’m inclined to agree with them, but I’d suggest they do it at a smaller size… maybe 24 or 32 px. Or use DirectWrite ClearType and get the best of all worlds (at least as far as Windows rendering options).

For WebINK, we’ve made it simple by rating each and every font for minimum usable size. For other fonts, check to see if the purveyor makes browser screen shots available, or just do a bunch of testing yourself.

To wrap it up, here are some detailed comparisons of different rendering so you can see the differences. Note how big the difference is, not only in the font samples but in the headings in Verdana!

Windows GDI ClearType samples

Windows GDI ClearType font rendering

Windows GDI ClearType font rendering

Windows GDI Grayscale samples:

Windows GDI grayscale font rendering

Windows GDI grayscale font rendering

15 Responses to “Why some fonts suck on Windows? Rendering and “hinting””

  1. Quora

    Does it make sense to use webfont services as long as most fonts render poorly on Windows?…

    I don’t think its fare to say that most of the fonts from the web font services render poorly on Windows. I think that a good percentage of the fonts render very nicely, I have heard many folks even prefer the rendering on Windows as it can be less fu…

  2. Richard Fink


    Firstly, I don’t know how the auto-hinted examples were done, but they are pretty poor.
    As Font Director at Kernest/Konstellations I look at auto-hinted fonts every day, and I’m somewhat mystified by what you’re showing. Our growing line of RasterBRIDGE® Web Fonts look far better. And all are auto-hinted.
    The unhinted fonts you’ve shown, well, their appearance is no surprise.

    One bone to pick: recommending a “minimum” pixel size for the CSS is worthless. It’s worse than making no recommendation at all because doing so implies that size can in some way be controlled by the designer but this is no longer so. The web has reached a turning point where the size of text – the actual, physical size – can’t be controlled at all, not even within a statistically predictable range. There are, today, simply too many variables for that.
    What matters is not the size as specified in the CSS, but the computed size, the size of the screen, and the sizing/resizing commands issued by user, and these things run a gamut way too long for designers to even wrap their heads around, let alone control. Yes, you need to enter a value for font-size. But in the age of Zoom, it means nothing. Control of the “size” of text is way out of the reach of the designer.
    What is the solution? Well, there isn’t any.
    And the reason is simple: there isn’t a problem. The medium has simply matured to the point that it was ultimately destined to reach – a point where designer’s have influence, yes, but absolutely no control.

    Cheers and a Happy and Healthy New Year,


  3. Thomas Phinney

    Hi Richard,

    Thanks for your comments!

    > Firstly, I don’t know how the auto-hinted examples were done, but they are pretty poor.

    They were done by using FontLab Studio 5.1 with default settings. FontLab Studio 5.x is the most common font generation and hinting tool in use today (though that is of course subject to change, at least on the hinting side). I agree that they don’t look great under some rendering options. That is rather the point!

    > Our growing line of RasterBRIDGE® Web Fonts look far better. And all are auto-hinted.

    It’s possible to tweak the auto-hinting process in varying degrees of course. And it’s possible to make additional manual font-specific tweaks of various sorts as inputs to auto-hinting, as we have done ourselves. My understanding from previous discussions is that you have done this with that particular set of fonts. It’s really a continuum from out-of-the-box auto-hinting to hand hinting.

    When you make manual tweaks to the inputs, I’m not sure I consider that to be several steps down that path. But choosing anything other than out-of-the-box would have involved a bunch of judgment calls. I chose the simplest comparison using the most common case I know of in the field, fonts that have simply been fed through FontLab Studio 5.x auto-hinting without any manual tweaks.

    > recommending a “minimum” pixel size for the CSS is worthless. It’s worse than making no recommendation at all because doing so implies that size can in some way be controlled by the designer but this is no longer so.

    Here I have to disagree on several grounds. First, we are simply telling users the minimum final size that will look good across browsers and devices. It is much better for them to have this information than not, and if we don’t give it to them, they will often either need to figure it out themselves, or be bitten by the problem.

    Second, the reality of zooming and usage of web sites is that text on sites is vastly more often zoomed larger than the specified setting than smaller. Larger is not a problem.

    > there isn’t a problem

    The problem is that sometimes web font text display sucks on Windows. I agree that by and large not having strict control over viewing zoom levels is not a problem for web fonts, or at least not a big one, but only because the text is rarely made smaller than the page-specified size.

  4. Richard Fink

    Sorry for the tardy getback.
    Thanks for your thoughtful response and for sharing your methodology.
    I suspected strongly that you would disagree with me on recommending minimum sizes. No biggie.
    Lately I’ve come to think of size as a much more important concern for font makers. To the point where, if a font I am post-processing doesn’t have an x-height sufficiently high, I rescale it as a matter of policy. With the web-safe fonts, or even the ClearType fonts for that matter, for fifteen years web designers have gotten used to seeing a font’s size fall within a range. But with some fonts, the font is scaled so small as a percentage of the em that writing “20px” gets you a size akin to Arial at 14px and at a size of 10px, well, there aren’t enough pixels available to render it anything close to legible. Or even pleasantly “Greeked”.

    To me, it’s a matter not so much about meeting expectations but of avoiding

  5. Thomas Phinney

    I’m curious about how you are changing the x-height, but that might be too involved a discussion for blog comments back and forth. The short question is, are you editing the outlines, or using TT hinting to increase the x-height at smaller px sizes? I have myself used the latter approach. However, that is getting pretty far from auto-hinted, and it won’t have any real affect on Mac and iOS, either.



  6. Beat Stamm

    Agree with your general assessment: It’s the interaction between individual fonts (with or without font “hinting” of some sort) and the rendering method (plain gray-scaling, ClearType, or Quartz, with glyphs laid down at integer or fractional pixel positions) that determines the outcome. Depending on type size and screen resolution, the combination of font and rendering method can prioritize such goals as verisimilitude of font design, crispness of font rendering, or stroke rendering contrast, but not all of the above with one and the same combination.

    By their nature, anti-aliasing rendering methods (including plain gray-scaling, ClearType, or Quartz) differ in their properties and yield different degrees of crispness or smoothness, amongst other. If the rendering method supports it, font “hinting” is an opportunity to exploit these properties to implement individual sets of priorities to different degrees. If the font rendering method expects it, this can become a challenge if the font maker is unaware thereof or unfamiliar with font “hinting.”

    The absence of expected font “hinting” is most easily noticed with “unhinted” fonts that have been designed and tested under Apple’s Quartz and are subsequently deployed on Microsoft’s GDI ClearType (Windows XP, Vista, and 7, Internet 8 and below, Mozilla FireFox 4 and below, Google Chrome, and Apple Safari on Windows with Font Smoothing set to Windows Standard). In y-direction, GDI ClearType renders much like pixilated black-and-white, with all the “Raster Tragedies” from the 90ies, and hence the inevitable need for font “hinting.”

    This problem is alleviated (not really solved) with the y-anti-aliasing component of DirectWrite (introduced with IE 9 and FireFox 5)—alleviated because it still requires font “hinting” to consistently exploit the potential crispness of the y-anti-aliasing filter used in the process, but it no longer looks anywhere nearly as “broken” as “unhinted” black-and-white rendering. At the same time, DirectWrite switches from glyphs laid down at integer pixel positions to glyphs laid down at fractional pixel positions. While this has the potential to vastly improve the inter-character spacing, it thwarts any intentions to carefully position strokes to maximize crispness in x-direction.

    By contrast, as far as I can tell, Apple’s Quartz discards any font “hinting” that may be present, which preempts font makers from exploiting the properties of the anti-aliasing rendering method, or from any other opportunities that font “hinting” may have. At the same time this also averts any negative consequences that flawed or defective font “hinting” may have (abundant use of unconditional delta instructions to improve black-and-white pixel patterns come to mind, or the results of inadequate auto-hinters). The price of the “hint-less” approach is fonts that look a bit fuzzy and emboldened, and—depending on the font height—appear soft, particularly along the tops of the lowercase characters or on crossbars.

    Hence here are the questions whose answers determine the final outcome on screen: Are the [web-]font makers aware of the different approaches pursued by Quartz (“least common denominator” to work reliably with any font) and ClearType/Directwrite (enabling to strive for the crisp rendering known in printing)? Do the [web-]font makers understand the potential of “hinting?” Are they willing to exploit the opportunities available with “hinting?” Willing to understand the challenges of “hinting” in terms of math and programming? Or willing to pay someone else to spend the time on math and programming? (And, for the money, better make that future-proof “hinting”)

    So… why do some fonts “suck” on Windows? The short answer is: Because they are not “hinted” properly! This may be for reasons of knowledge, economics, or possibly politics, but it’s up to the font makers to make that call.

  7. Scott F

    Thanks for this article on a frustrating problem. As one of the few Linux desktop users out there, I was surprised to find out it’s Windows, not Linux, that’s lagging behind in typography. Some of my favorite fonts absolutely bomb under ClearType, and even when properly hinted, I feel text on Windows has a cold, digital look. It’d be interesting to see some three-way screenshot comparisons between ClearType, FreeType and Quartz — I suspect Quartz would look the best but ClearType would be the obvious loser. (And blaming font designers for not hinting properly seems a weak excuse when the competing renderers do just fine with unhinted fonts.)

  8. mauro

    ChaparralPro-Regular seems to be the culprit in making the site look rubbish in windows 7 – as soon as I disable that the fonts smooth nicely.

  9. Thomas Phinney

    Sporkinator: If you turn off font smoothing, we can’t be responsible for your results. The default on XP is font smoothing on but ClearType off, and under Windows 7 it’s ClearType on (which includes font smoothing). The text looks good under both those environments.

    mauro: That’s the font we are using, and it looks pretty good to us in Windows 7. I’d be curious to see a screen shot of what you are seeing, but you did not leave an email address.

  10. Tiago Almeida

    This is what I see in Chrome latest version and windows XP (work PC).
    I think this is terrible. Notice how the O’s and the T’s do not have the same width throughout the body, for instance.
    I came to your site specifically to find a solution for this problem that I face in many sites.
    Do you have any idea? I am using the Standard method to smooth edges. ClearType makes it a bit better but actually makes everything else blurry as hell so it makes it harder to read.
    Not using the smooth edges looks the same as it is now.

    Many Thanks


  11. Thomas Phinney

    Tiago: Your screen shot is very different from what we get in testing on XP. Are you sure you are using “standard” smoothing? I ask because what you are showing looks like font smoothing is OFF. Or perhaps you have hardware accelerated rendering on in Chrome?

  12. Tiago Almeida

    Ok, I see the issue. The standard smoothing was not on when I tried. I changed it to Standard and because some windows / programs actually changed, I assumed the change was instant. For Chrome I had to kill it and relaunch.
    I can read without crying now :D


  13. Jeff

    When I saw the title of this article I felt hopeful that there would be a link to some application or library or set of instructions to make font rendering less terrible on Windows 7. Guess I will have to keep searching.


Leave a Reply