Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Avoiding Faux Weights And Styles With Google Web Fonts

If you’re using Google Web Fonts on your websites, then there’s a very good chance that 1 in 5 visitors are seeing faux bold and italic versions of your fonts — even if you correctly selected and used all of the weights and styles. That’s because the implementation method recommended by Google Web Fonts doesn’t work with Internet Explorer 7 or 8.

As an experienced print and Web typographer, I embrace and use the term “font” when talking about Web fonts; it’s the term used in CSS syntax and by a myriad of Web font providers.

Further Reading on SmashingMag: Link

Faux Bold And Italic Fonts Are Stretched And Slanted Link

Any designer who loves type will tell you that faux bold and italic aren’t beautiful. When a browser can’t find the true bold or italic version of a font, it will often “fake it” — creating faux bold and italic by stretching and slanting the original font.

Faux Bold Link

Faux bold is made by slightly stretching the vertical strokes of the original font. In the image below, I’ve used Droid Sans Bold, which has consistent strokes. Yet in the faux bold, the vertical strokes are a little thicker than the horizontal strokes. This is most noticeable in the letter “e”; the top of the letter, where the stroke is thinnest, looks pointy.

A faux bold (top) slightly stretches the vertical strokes of the original font. This creates odd shapes, like the pointy top of the letter “e.” A true bold (bottom) is more consistent between horizontal and vertical strokes.

Faux Italic Link

Faux italic is made by slanting the original font at an angle. In the image below, I’ve used Droid Serif italic. The faux italic is missing the tail on the lowercase “f,” while the lowercase “a” continues to have the double-story shape. In a true italic font, the “f” and “a” look more calligraphic — or handwritten — especially in serif fonts. If you’ve chosen a serif font for an older, more traditional feel, then you’ll probably want to preserve these true characteristics of italic.

Faux italic (top) is made by slanting the original font. True italic (bottom) often has traditional calligraphic characteristics, such as the extended stroke on the “f,” the single-story “a” and the rounded “e.”

Faux Bold Italic Link

Faux bold italic both stretches the vertical strokes and slants the letters at an angle. The resulting letters are clunky compared to the rhythm and texture of a true bold italic.

Faux bold italic (top) is both stretched and slanted. True bold italic (bottom) has a thoughtful rhythm and texture.

Faux bold and italic are not as beautiful as the real thing. But when it comes to text, even more important than beauty is readability.

Faux Bold And Italic Undermine Reading Link

Faux bold and italic are often less legible, which in turn undermines the readability of text. When letters are stretched and slanted, the strokes and spaces are no longer well balanced.

Well-Balanced Strokes and Spaces Improve Readability Link

If you’ve ever had to read a bad photocopy (or scan) for a class, conference or meeting, then you already appreciate how important strokes and spaces are for reading complex text.

Reproductions that are too dark or too light are hard to read. Too dark and we lose the spaces in the letters (left); too light and we lose the strokes in the letters (right).

If a photocopy or scan is too dark, we lose the spaces in and around the letterforms. If a photocopy or scan is too light, we lose some of the strokes in the letterforms. In both cases, text is less legible. Reading speed slows as we try to identify the letters and words. We experience brain fatigue as we find ourselves rereading phrases to make out the words, leaving less energy for comprehension.

A good balance between strokes and spaces improves legibility and helps us read more quickly and easily.

Faux Bold, Strokes and Spaces Link

Because faux bold is created by stretching the vertical strokes of letters, the top and bottom strokes on rounded forms are often too thin. This makes letters like “e,” “c” and “s” start to break on the top and bottom curves. Meanwhile, letters with a diagonal stroke, such as ”w” and “N,” get too heavy and start to pop out of the rhythm of the text.

Droid Sans bold. The faux bold (top) is slightly less legible. The tops and bottoms of the rounded letters — like “e,” “c” and “s” — tend to disappear. Diagonal letters, like “w” and “N,” are too bold. True bold text (bottom) is more consistent.

Faux Italic, Strokes and Spaces Link

Because faux italic is created by slanting the original font at an angle, the spaces in the letters get condensed. This is a particular problem in the lowercase “a,” which continues to have two counterforms. Ironically, while faux italic letters feel more squished and are more difficult to read, they often take up more room, and fewer characters fit on a line.

Droid Serif italic. The faux italic (top) is less legible. Spaces within the letters are more condensed. The text itself feels smaller, even though fewer characters fit on each line. True italic (bottom) is not just more visually pleasing, but more legible and, thus, easier to read.

Fixing Google Web Fonts Bold And Italic In IE 7 And 8 Link

Because real bold and italic fonts are usually more beautiful and more readable than their faux counterparts, we should make them work on as many browsers as possible.

As is usually the case, figuring out how to fix the problem starts by understanding why the proper bold and italic fonts don’t work in the first place.

In “Say No to Faux Bold1911,” recently published on A List Apart, Alan Stearns reminds us that a good start is to use fonts for which bold and italic styles are available — and to actually include the bold and italic styles that you need when choosing the fonts in the Google Web Fonts interface.

But choosing and using bold and italic styles aren’t enough.

Multiple Weights and Styles Don’t Work in IE 7 and 8 Link

Google Web Fonts instructs us to implement its fonts by checking off all of the font weights and styles that we want to use, then copying the link it provides, and pasting it into the head of our HTML document.

For example, to use Droid Serif regular, italic, bold and bold italic, we would select all four weights and styles, like so:

Droid Serif on Google Web Fonts

In response, Google Web Fonts will create a link to all four styles:

<link href=",400italic,700,700italic" rel="stylesheet" type="text/css">

This link points each browser to its own browser-specific source. For example, Firefox is taken to a document that returns the @font-face declarations below. Note that the declarations use the same font-family name each time. This would cause a problem in IE 7 and 8, which don’t recognize multiple styles and weights that use the same font-family name.

@font-face {
font-family: 'Droid Serif';
font-style: normal;
font-weight: bold;
src: local('Droid Serif Bold'), local('DroidSerif-Bold'), url('') format('woff');

@font-face {
font-family: 'Droid Serif';
font-style: italic;
font-weight: normal;
src: local('Droid Serif Italic'), local('DroidSerif-Italic'), url('') format('woff');

@font-face {
font-family: 'Droid Serif';
font-style: italic;
font-weight: bold;
src: local('Droid Serif Bold Italic'), local('DroidSerif-BoldItalic'), url('') format('woff');

@font-face {
font-family: 'Droid Serif';
font-style: normal;
font-weight: normal;
src: local('Droid Serif'), local('DroidSerif'), url('') format('woff');

One way around the “single font-family, multiple weights and styles” problem is to send IE 7 and 8 to a different source. Google Web Fonts does this, but unfortunately the @font-face declaration looks like this:

@font-face {
font-family: 'Droid Serif';
font-style: normal;
font-weight: normal;
src: url('');
src: local('Droid Serif'), local('DroidSerif'), url('') format('embedded-opentype'), url('') format('woff');

This doesn’t help us. The single declaration sets the font-weight to normal and font-style to normal, thus forcing IE 7 and 8 to “fake it” when requested to render bold and italic versions of the font.

The result? Faux bold and italic — even if we had carefully selected a font with bold and italic styles, and even if we had implemented all of the weights and styles as instructed.

Droid Serif. IE 8 delivers faux bold and italic (top) because it works only with a single @font-face declaration and a single font-family name. Firefox delivers true bold and italic (bottom) because it can handle multiple weights and styles that are assigned to a single font-family.

A Common Fix Causes Problems in Opera (and Android) Link

A common “fix” for this problem is to insert separate links — one for each of the styles and weights used — into the head of the HTML document. That is, we select each weight and style of the font separately, taking the time to copy and paste each unique link into the head of the HTML document. The syntax for Droid Serif would look like this:

<link href="" rel="stylesheet" type="text/css">
<link href="" rel="stylesheet" type="text/css">
<link href="" rel="stylesheet" type="text/css">
<link href="" rel="stylesheet" type="text/css">

While this solves the problem in IE 7 and 8, referencing four CSS files for a single font family increases the number of requests that the client makes to the server and contributes to latency14. The fix also creates a new typographic problem in Opera (including Opera Mobile on Android). Opera renders text using the last weight and style served; so, if the last weight and style served is bold italic, then the font will come in as bold italic over the entire page.

Droid Serif. Using separate links to each weight and style fixes the problem in IE 7 and 8 (top), but it causes problems in Opera (bottom). Opera renders text using the last weight and style served.

Using a Conditional Comment Works Across Browsers Link

There’s a better solution: adding a conditional comment. IE 7 and 8 are the only browsers that need the fonts to be served separately. And because conditional comments work only in IE, the solution is solid. The new syntax looks like this:

<link href=",400italic,700,700italic" rel="stylesheet" type="text/css">
<!--[if IE]>
<link href="" rel="stylesheet" type="text/css">
<link href="" rel="stylesheet" type="text/css">
<link href="" rel="stylesheet" type="text/css">
<link href="" rel="stylesheet" type="text/css">

Notice how all browsers except IE are instructed to use the usual method for accessing Google Web Fonts. This keeps bold and italic fonts loading correctly (and more quickly) in Firefox, Opera, Chrome and Safari. Meanwhile, IE is instructed to access each weight and style separately. This fixes the faux bold and italic problem in IE 7 and 8, and it doesn’t create any new problems in more recent versions of the browser.

Using a conditional comment, we get true bold and italic to load correctly across browsers. Top to bottom: IE 8, IE 9, Firefox 11, Google Chrome 18, Safari 5, Opera 11.62.

Help Visitors Enjoy Their Reading Experience Link

If people are on your website, they’re probably either skimming quickly looking for something or they’ve found what they’re looking for and want to read it as easily as possible. Either way, keeping the text readable will help them achieve their goal.

Bold and Italic Help Organize Content Link

From a macro perspective, bold and italic forms of a font are important for people skimming your website. Bold and italic forms add emphasis — both strong and subtle — to text. They can help visitors understand the organization of content before they even start to read it.

Bold and italic create levels of emphasis, which helps to visually organize text (left). The same text without bold or italic (right) would feel more like a narrative.

True Bold and Italic Are Easier to Read Link

From a micro perspective, true bold and italic forms are important for people engaged in more sustained reading on your website. A proper balance between strokes and spaces improves legibility and makes text easier to read, thus minimizing brain fatigue and giving visitors a more pleasurable experience of the website. Type designers use their time and talent to create Web font families that are both legible and beautiful; for us, it’s just a matter of getting the true weights and styles to load properly.

True bold and italic text is not just more visually pleasing, but also easier to read.

Waiting until Google fixes this problem might be tempting, but it’s been on Google’s radar since June 2010. Making sure that the bold and italic fonts served up by Google Web Fonts work across browsers is up to us. And it takes only a minute. Don’t let 1 in 5 visitors to your website down.

Further Resources Link

(al) (il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21

↑ Back to top Tweet itShare on Facebook

Laura Franz is a Pro­fes­sor at UMass Dartmouth, where she teaches a wide range of type classes — including a Web Typography class in The Grad­u­ate Cer­tifi­cate In Web and Inter­ac­tion Design. Inspired by the intersection of tradition and technology, Laura shares her web font recommendations on and her typography knowledge via “Typo­graphic Web Design: How to Think Like a Typog­ra­pher in HTML and CSS” (Wiley), “Typog­ra­phy for Web Design­ers”, and “Choosing and Using Web Fonts”.

  1. 1

    Martin Bean

    July 11, 2012 1:09 pm

    If using conditional comments to load the individual stylesheets for Internet Explorer, could you wrap the combined stylesheet in a non-IE conditional comment? As the contents of the combined stylesheet would be loaded for IE, then overwritten by the individual ones would it not?

    • 2

      Laura Franz

      July 11, 2012 4:11 pm

      I think you’re suggesting something along these lines?
      < !- -[if IE] >
      Link to separate fonts for IE
      < ![endif]- ->
      < !- -[if !IE] >  
      Link to combined fonts for all other browsers
      < ![endif]- ->

      I haven’t tested this and do NOT KNOW if it works. I have never seen non-IE browser conditions set nested in conditional comments. I’ve often seen them set separately, like this:

      < !- -[if IE] >
      Link to separate fonts for IE
      < ![endif]- ->

      < !- -[if !IE] >  
      Link to combined fonts for all other browsers
      < ![endif]- ->

      I’d be interested in your perspective on why you prefer using a non-IE browser syntax. In my mind, the two work similarly.

      I tend not to use the non-IE browser method because the syntax says: take this style that works in non-IE browsers, and wrap it in syntax to make it work in non-IE browsers. This could be because I work on a mac, testing cross browser periodically through the building process (rather than working on a PC and testing periodically). So I tend to think in terms of needing to “fix” for IE.

      Also, a note: if I find a problem with IE browsers I *always* try and fix it without having to use conditional comments. But there’s just no work around with Google fonts!

      Another reason I prefer to keep the different approaches (linking to combined vs individual fonts) separate and clearly “marked” is it helps beginning and intermediate html/css users. I think the syntax is easier to parse, understand, and use in a different context.

      Again, I’m very interested in your perspective!

      • 3

        I think he might mean something like this:

        <!--[if gt IE 8]><!-->
        <link href=",400italic,700,700italic" rel="stylesheet">
        <!--[if lte IE8]>
        <link href="" rel="stylesheet">
        <link href="" rel="stylesheet">
        <link href="" rel="stylesheet">
        <link href="" rel="stylesheet">

        It should work, the first rule for IE9 and all the browsers that ignore conditional comments, the second rule for old IEs.

  2. 4


    July 11, 2012 1:32 pm

    Even as a constant user of Google Web Fonts, I really didnt realize there could be such a drastic problem (although I was aware of Droid Sans distinct caligraphic italics which did not render so when I made the mistake of not including the italic type in my stylesheet).. Thanks for the info :)

  3. 5

    Panayiotis «» Velisarakos

    July 11, 2012 1:57 pm

    Very interesting and thorough article, thanks! I have actually done some research for that matter too (in Greek, unfortunately) with the Open Sans Condensed:

  4. 6

    Great article!

    I’ve been using Google fonts for my clients’ websites for a while now and couldn’t figure out why some of them were telling me that the fonts were not smooth in their browsers.

    I am going to revisit those “problem” sites later today and add your solution to fix the IE issue.


  5. 7

    Brian Handscomb

    July 11, 2012 2:58 pm

    I can’t believe I am defending IE here, but it strikes me that the error is in Google’s court, not something that IE can be blamed for as suggested in the article – IE can and will quite happily support real bold and italic versions with the same family name as the “regular” font, though it has to be said it has very strict rules stating that for it to work the internal names must match.

    The actual problem is that Google only gives ONE font face rule when IE requests a multiple weight CSS file (which the article actually states). Bad Google! :)

    The solution is, however, exactly as per the article says, and then Google will provide IE with as many font face rules as other browsers. And for anyone curious, it does so using the same single family name for each of the italic, bold and bold italic fonts.

  6. 8

    Abhimanyu Rana

    July 11, 2012 4:13 pm

    Now, this is what im looking from long time. Thanx for Share

  7. 9

    Thank you. I am designing a site that uses Tangerine in the logo and the bold in IE was hideous. Changing the code now.

  8. 10

    James George

    July 12, 2012 4:47 am

    This is an extremely informative post. I am really excited to try this out. This is pretty brilliant and a great way to solve a serious problem. Kudos for not accepting things as they are, and for finding your own solution!

  9. 11

    I loved this article, I didn’t know about the IE7-8 problem!

    Easy fix too, thanks!

    Wouldn’t it be better to use <!--[if lte IE8]>, though? I’m assuming the usual declaration works in IE>8.

  10. 12

    A timely article, as I’ve wrestled with the faux bold issue for a while now. I honestly never thought to use a conditional statement. Thank you, Laura.

  11. 13

    Laura, thank you so much for this article. This has been a problem plaguing me of late.

    I’m having an issue in IE 7 and 8 where when I load the page I see that the bold font displays properly, then when the page finishes loading it switches to a faux bold. I’m wondering if anyone else has run into this issue.

  12. 14

    Josh Einstein

    August 9, 2012 3:46 am

    Wow, just for the hell of it I went into the Chrome developer tools and altered the font on this web site so that it degraded to web safe fonts. It totally made the difference between being awesomely sexy or ugly as a tranny on a low budget. These little typography details really do matter.

  13. 15

    Christopher Simmons

    October 5, 2012 2:23 am

    Awesome … I was using the open sans and running into this very problem (I went to CompuGraphic typesetting school in ’85… so right with you on the “real” vs “faux” italics/bolds). THIS SOLVED it for me. THANKS!! :-)*

  14. 16

    I think that maybe Google changed something? My sites using this technique break now, while they worked a few weeks ago.

    Is it just me?

  15. 17

    Jeslin George

    November 3, 2012 7:03 am

    This is what gives any design the final touch of elegance, what keeps an amateur design separate from the professional one. Although I feel that the number of people using IE 7 and 8 have gone down drastically and will keep going down, hence don’t think this should be a major issue over a period of time

  16. 18

    Great, very usefull !

  17. 19

    How does this work with WordPress premium themes that offer the different google fonts? I’ve noticed with my thesis theme the faux bold and it drives me crazy. Do I add the code into the custom.css part of the theme?

  18. 20

    I am limited in being able to add the conditional load solution in the head because it’s in a Drupal site, and the developer doesn’t want to load the fonts in the head that way. Is there any way to use the IE conditional to link to an ie-typography css file that uses @import to call each font individually?

  19. 22


    i m using google web font PT Sans Narrow,

    wp-theme in header part ;

    <!-- -->

    It’s not working in ie8, anyone can help me.

  20. 23

    Just tried to implement the multiple stylesheet calls solution described here but it still doesn’t work in IE7/8 (perhaps Google have changed something). It tried this (I’ve omitted the beginning and closing tags as this form stripped everything out when I first pasted in the stylesheet links):

    rel=’stylesheet’ id=’g_font_ie-4-css’ href=’//’ type=’text/css’ media=’all’
    rel=’stylesheet’ id=’g_font_ie-5-css’ href=’//’ type=’text/css’ media=’all’
    rel=’stylesheet’ id=’g_font_ie-6-css’ href=’//′ type=’text/css’ media=’all’
    rel=’stylesheet’ id=’g_font_ie-7-css’ href=’//’ type=’text/css’ media=’all’

    But the last call for bold italic has no effect. If I switch up the order so that the call for bold italic is the first stylesheet, bold italic does work properly (so in other words, IE7/8 only uses the first stylesheet and not the others if the font name is the same).

    The fix described here doesn’t seem to work (unless I’ve done something wrong). Either way, I don’t actually understand the logic of why it would work. Can anyone explain this? Surely the code that gets loaded using separate stylesheet calls is the same code that loads when using the single call that Google recommends. It’s just not aggregated onto one stylesheet. No?

    Many Thanks,


    ps I was trying to find a solution to this so I could add the functionality to my WordPress plugin for Google fonts (among other things):

  21. 24

    Thanks for the informative post. I have one question, though: won’t selecting a bunch of different styles and weights have an impact on the page loading time? How do you get around this?

    • 25

      The article fails in that respect, as it’s basically suggesting you load the fonts plus all it’s different weights on a page. You could be looking at between 4 and 8 fonts, which has a huge impact on page performance. Additionally, you will see impacts to page rendering and scroll performance on touch devices by including/utilizing that many fonts. 2 fonts with minimal usage on the page, is the preferred maximum when keeping performance in mind.

  22. 26

    This tricks doesn’t work for me with the open sans family…


↑ Back to top