Issue № 371

The Era of Symbol Fonts

Improving performance is a constant process. First we ditched tables, spacer gifs, and inline markup such as the <font> element in favor of CSS, reducing page sizes, and separating style from layout. Then we became aware of all our DNS requests, caching, and the total number of files and started using CSS sprites, moving many small images out of the HTML and into a single background image.

Article Continues Below

Now it’s time we embrace the third epoch in performance optimization: symbol fonts.

Embedding a symbol font lets us move some of those tiny icons into a single font file rather than a sprite. This has the same caching and file size benefits as a CSS sprite, as well as some additional benefits we’re only now realizing with high-resolution displays. In this article, I’ll walk you through some of the advantages and issues you’ll encounter when using a symbol font.

A smooth experience#section2

As the number of fonts designed for use as icons, glyphs, and decorations increase, several high-traffic websites have replaced all the images on their site with a single symbol font. One of the best-known examples is GitHub, which has improved both its speed and its user experience by dropping all its tiny icon files in favor of Octicons, a single, custom symbol font file.

Symbol fonts trade blocky raster images for smooth vector images in your HTML. This is important because rasterized images are designed to work at a specific resolution, so at higher pixel densities, like those found in today’s high-resolution displays, the images must be scaled up to appear the same size. This results in something that looks more “blocky.” Vectors never have this problem, scaling endlessly up or down for any resolution.

Embedding vector graphics into HTML has had limitations in the past. PDF and SVG are possible, but create interoperability problems. Fonts are vectors and all web browsers, even IE6, have the ability to render embedded fonts in an HTML page. This convergence of technologies—font embedding, high-resolution displays, and browser support—has created a new opportunity to further optimize performance and user experience.


When it comes to accessibility, symbol fonts are in the conflicted situation of working poorly as images, yet quite well as text.

Many of the early symbol font services mapped the graphic to a letter in the ASCII range. Typing a “w” would produce a picture of a globe, typing an “m,” an envelope. This made it easy to see the character-to-symbol conversion simply by typing. Problems would occur when the font embedding failed, ending up with strange letters in random places that didn’t make sense. For instance, if your markup was meant to display an arrow, then the text “Next,” the HTML might look like:

<div><span class="icon">L</span> Next</div>

But if the CSS, JavaScript, or font loading were to fail, you would see the character “L” rather than the symbol for a left arrow. You could put all the fallbacks in place, inject the code with JavaScript or CSS :before or :after, but at the end of the day, search engine spiders might still index that text as “L Next.”

There is a better way.

We’ve matured, learned more about these issues, and solved the problem by using the private-use area in Unicode. The glyphs in this area are not connected to the semantics of any letters of the alphabet. If the font isn’t available or doesn’t load, then an empty box will appear instead of a letter.

But wait—we can improve even more!

Fonts also have special characters called ligatures—subtle, often hardly noticeable, tweaks to the letterforms that are used to aid reading. Take, for instance, two consecutive “f” characters. A good font will convert that “ff” into a single ligature where the fs connect smoothly. There are several standard ligatures, including ff, fl, and fi. But there is no reason you can’t also define your own. In a font file, it is a simple substitution; all the ligature is looking for is the right sequence of letters. When they’re typed, they are replaced with another glyph. This means you can have a string like “A List Apart” and convert it into a single symbol icon of the logo.

Browsers that don’t support font embedding—namely, search engine spiders—will index the raw un-ligatured text, but devices capable of rendering the font and ligature will show you the nice vector symbol instead. It’s the best of both worlds, baked in at a much higher level than HTML and CSS.

Once you understand how ligatures work, a world of new possibilities opens up! All those mystery-meat icons used in navigation could be symbols in a font, but beyond that they could be ligatures. So your HTML markup might look like:


But the resulting rendered ligatures might look like:

Symbolset has been experimenting with ligatures and symbol fonts for a while, and now sells packs of symbol fonts with commonly used icons. It also has great ligature support, and a demo where you can simply type keywords and watch them snap to symbols immediately. Don’t be surprised if this makes your mind race with ideas.

Using ligatures as glyph substitutes has practical applications. For example, the BBC News website formerly featured a ticking clock in the corner of the homepage. The clock could have used Flash, but that would have been ill-advised given its lack of support and the existence of alternatives. Another option would have been to use CSS to rotate images of the hands with a little JavaScript timing. Instead, the BBC chose HTML5, using Canvas plus JavaScript to continually redraw the clock face.

But both these non-Flash solutions use rasterized images that wouldn’t look as nice on high-resolution displays. There are JavaScript libraries, like Raphaeljs, which can create SVG or VML objects that would be nice and vectorized, but since they are loaded and created in JavaScript, they would be invisible to search engine spiders or other non-JavaScript browsers.

Using a symbol font instead would give you the best of both worlds: accessibility and vectors. Typing 12:00 would call up a ligature, which would convert to a clock with both hands at 12. Typing 12:01 would be a different ligature for the corresponding clock face. While there would be a lot of ligatures to create, the resulting clock would be a beautifully designed vector graphic that would work across platforms. In fact, a few clock typefaces are already doing this; has several examples. Go ahead—view source, and you’ll see its simplicity. [Ed. note: We restored the link to after hearing from the site owner that the issue had been addressed, and after running our own scan.]

Think about all a web page’s little details that could be symbol fonts. Open your mind to the possibilities. Everything from bullets and arrows to feed and social media icons could be bundled into a single, tiny font file that can be cached and rendered at various sizes without needing multiple images or colors.

Creating your own symbol font#section4

Web developers and designers cut their teeth on applications like Photoshop, Fireworks and others. For us, moving to CSS sprites or background images wasn’t a big leap because the tools didn’t change. With symbol fonts, a new program enters into the mix: the font editor. This is a new beast we need to learn, but it’s not that difficult.

Even better, plenty of tools are being released to aid in symbol font creation. For example, Icomoon lets you upload your SVG files, map them to unicode characters, and export a font for use online.

What if you want to get more specific and tweak the design beyond its default displays? There are several tools out there to create your own fonts. A few are paid, professional apps, but the most common free tool is FontForge. It’s a bit unwieldy, but there are many tutorials out there to help you use it.

Issues with fonts#section5

As any good designer will tell you, an icon or logo will have subtly different designs at different sizes, such as changing its line thicknesses or even dropping some of its detail at small sizes. With a symbol font, however, you can’t have alternative designs for different font sizes. Your design at 20 point must be the same as at 120 point or 6 point.

If you want different designs at different font sizes, then you need to duplicate the icon in the font file and select the appropriate glyph depending on the usage. This too is problematic, because you have no idea how the end user will actually view your design. Increasing the font size in their browser natively won’t switch your symbol design. For most of us, this isn’t a problem, as many of the utility icons we use today for feeds and social networking scale relatively well.

The other major issue with using a symbol font is that you only get one color. You can work some magic with background colors and font gradients to emulate a two-color logo, but if your icons are multicolored, then the current symbol font setup won’t work for you.

To remedy this, Apple is proposing multicolor fonts, which would let you create and embed pure vector graphics into any web page. Its first foray into this field is the Apple Color Emoji font, which you might already have if your machine runs OSX Lion. The downside of introducing a new font format is the lack of browser support and font creation tools needed to come up to speed, which means it might be a while before this becomes a reality.

Welcome to the next epoch#section6

Symbol fonts are the next step forward in website design and optimization, and you need to understand them to work on the web today. With practice, you can create your own custom symbol fonts with logos, icons, and branding to embed into your websites. Not only will these little extras impress your audience, but they will simultaneously optimize your website’s performance. It’s time we all start using symbol fonts—and help improve the tools, standards, and techniques to make them.

43 Reader Comments

  1. A other thing to consider when designing your icons is localisation. One icon may mean something to us in the western world but is meaningless to a person in an Asian country.

  2. Some nice ideas, thanks.

    Sadly there are some problems with using fonts not mentioned…

    1. Font hinting – Google Chrome on Windows does not do font-hinting correctly meaning that your lovely symbols can start looking blocky. Maybe this will be fixed in a future release?

    2. Example – does not work, appears to have some bing ad search breaking it in FF and IE9, and Chrome does not appear to render the font at all.

    3. Alignment – I have found that correct vertical alignment of symbol fonts is normally harder to achieve cross browser than images, I cannot give any solid examples, but I found switching to using symbol fonts required a lot more conditional css than images.

  3. I’m skeptical that most websites would see a performance improvement in switching from images to symbol fonts. Github is doing it close to optimally:

    – custom webfont that has exactly what they need (26k)

    – loaded in js to minimize downloads (only one of woff and eot)

    – served with very long cache lifetime

    – served via cdn

    But even then they have the problem that all text display has to wait for the font to download.

    Most sites are going to skip some of these, so I expect the change to symbol fonts to hurt most websites that try it. If you do try it, definitely A/B test it to make sure it really is speeding up pageloads for your users.

  4. I have been using icon fonts for a little while now, but creating ligatures instead is genius! I wish you had elaborated a bit more on how to actually create and use them though. According to Icomoon and IE9, Opera, and the Android browser don’t support ligatures at all, so it seems like implementing them reliably might not really be an option yet.

  5. Just wanted to note that our corporate proxy is currently detecting an embedded Trojan on the page. Not sure if this is a false positive, but please exercise caution when going to that site.

    Content contained “Trojan.JS.Redirector.xb” virus. Details: Virus: Trojan.JS.Redirector.xb; File: No file name available; Sub File: Memory region; Vendor: Kaspersky Labs; Engine error code: 0x00010000; Engine version:; Pattern version: 130312.121800.9678883; Pattern date: 2013.03.12 12:18:00

  6. tesmond is correct, symbol fonts have a vertical alignment bug between PC and Mac. Learn more –
    You have to use OS sniffing to fix it. And not all fonts are created equal. I was using the free symbol font Entypo and it has a large height (not the icon itself, the space that the icon resides), which causes this alignment bug to have a pretty significant vertical shift between PC/Mac. In my case the icon was positioned 40 pixels higher on Mac.

  7. I’m using a custom-made symbol font, and I found that a line-height of 0.6 renders fairly consistently across browsers and Mac & PC.

    Also for IE 8 & down, if you use a filter to turn off ClearType on your text, the symbol-fonts will render much smoother:

    .lt-ie9 .old-ie-font-fix {
    background-color: white;
    opacity: 0.99;
    /* IE 8 */
    -ms-filter: “progid:DXImageTransform.Microsoft.Chroma(color=’white’) progid:DXImageTransform.Microsoft.Alpha(opacity=99)”;
    /* IE 6,7 */
    filter: progid:DXImageTransform.Microsoft.Chroma(color=’white’) progid:DXImageTransform.Microsoft.Alpha(opacity=99);

    The color you assign to background-color and the color in the filter has to be the color that’s behind the font, so you might have to make multiple classes for multiple colors.

  8. Good article! However, like tesmond mentioned, differences between browsers / OS in rendering the fonts are a major problem.

    For I’ve used a custom symbol font for all of the nav icons and as well as for the mobile version logo [basically everything I’d normally use a SVG file for].

    The fact that the fonts are white further attributed to rendering issues. I can imagine you might actually need to create a dark and a light symbol version in some cases.

    I experienced no problems with the font vertical alignment, and if you create the font correctly I don’t see why you should get such issues.

  9. In my experience, custom fonts are only as good as you don’t count WebKit. Unfortunately, WebKit is powering 100% of mobile devices and about 30-40% of computers. That’s a lot.

    WebKit will introduce a lag between pages where you will see your text rendered with the default font before displaying the custom font. Even of the custom font is already cached and downloaded. This is not the case with a png.

    For me, advocating custom fonts for graphics is doing a disservice to your users. It just doesn’t work with WebKit.

  10. @pieroxy:

    I believe you’re talking about what Mozilla does.

    In our experience, Webkit displays *no* font until the font loads. Then it displays the web font. No harm, no foul, no problem.

  11. This is a good summary of the basics of icon webfonts, but I should point out a few points that aren’t 100% true …

    You say “a good font will convert that ‘ff’ into a single ligature where the fs connect smoothly”, but this is a bit misleading. If a font doesn’t have an ff ligature, it doesn’t necessarily mean it is not a good font. It may just mean its f was designed in a way that might not require a ligature when set next to itself. Also, not all ff ligatures necessarily connect the two f’s together. Some ligatures simply modify the shape to work better in that context, without connecting anything.

    You also say “you can’t have alternative designs for different font sizes”, but theoretically one could add hinting instructions to their icon font to adjust the design for different sizes in Windows. Granted, those adjustments would be all but ignored in Mac though, so you are right that there isn’t a reliable cross-platform way to have size-specific variations. (This is the kind of problem I discussed in my piece on font hinting, explaining how a more general implementation of responsive typefaces would be helpful.)

    These are relatively small corrections in the grand scheme of your article, but I figured it was worth pointing them out.

    Also worth mentioning as a reference for existing icon webfonts, Stephen Coles put together the Icons as Webfonts list on Listgeeks.

  12. I understand that at the moment icon fonts seems like a good solution, but it still a hack. It’s like using tables for layout: temporary workaround due to immaturity of technology. You want vector icons? SVG is a standard for this. Don’t be mistaken: hack is a hack.

  13. @Dmitry – Symbol fonts have been around since the dawn of typography. There is nothing wrong with this approach. Its not a hack, but rather a natural extension of typography. As someone that was in the desktop publishing industry and taught traditional print folks (around the country) to come into the digital age, I can tell you there are probably more folks out there that would think this is completely natural than the other way around (but I’ll admit maybe less who are digital-only folks).

    To see why this makes much sense, you should stop separating the ideas of ‘ideogram’ and ‘glyph’. The copyright symbol is an ideogram (icon) because it conveys meaning of a concept. Should it not be included in fonts? Icons display meaning. They shouldn’t be in fonts? If you say only glyphs should be in fonts, then we have a big problem and we’ll have to remove all sorts of ‘characters’ that are treated as glyphs but should not be in fonts because they are really ideagrams.

    Browser tech will probably never get an elegant UNIFIED solution for associating a symbol with a block of text. Wrapping a symbol with some text inside nested div tags is really the hack when you think about it. Using CSS psuedo elements (:before + content:) to embed an icon in a block of text is also a hack.

    No, fonts and ligatures are acutally much better for several reasons: You get automatic scaling and alignment of the symbol with text, both sharing the same baseline, with an expectation of consistent rendering – this is huge! The ability to associate a semantic meaning with a symbol through the built in ligature feature of font definition files is huge! The ability of the community to strong arm browser companies to follow the font standard to support ligatures will enable designers to use this very powerful tool, a tool that won’t be replaced for possibly decades!

  14. I love this idea, but there is an accessibility bug about it. If you consider people with learning disabilities in your design, you should be showing the icon with the word as they may struggle with the meaning of the icon.

    With that in mind, if I use the ligature method to show an icon of a house followed by the word Home the code would be

  15. Home Home
  16. . Which isn’t a problem until someone using a screen reader comes along and looks at the nav which is then read as “List element, link, Home, Home”. It becomes annoying redundant redundancy.

  17. @Greg – I agree this is sticky. At the risk of being seen as suggesting a hack(!) I would say that wrapping symbols in a span tag allows you keep the inline nature of the rendering (blocks have much different rendering aspects) and then you can hide the symbol for the screen media type:
    @media speech {.symbol { display: none; } }

    Maybe some change will come along that will allow you to select just the text of the symbol font (attribute property selection) ala:
    @media screen { .menu_item[style::font-family=my_symbol_font] { display: none; } }
    Wouldn’t that be cool! There are also a couple of ways to select span elements of a given font family with jQuery.

  18. Hi There,

    Thanks for the great article.

    The only gripe is that I wish that you had also talked about the method used for Glyphicons in Twitter Boostrap (and now Font Awesome), which seems pretty brilliant to me. The icon sits in a semantically neutral tag while you can make the link text say whatever you want (with accessibility in mind).

    <a href="index.htm"><i class="icon-home"></i> Home</a>

    It seems to me that this technique has a lot of advantages. What do you think?

  19. Excellent article! Thanks for all the links; that really got me started.

    Just expanding on ligatures and the clock. Would it not be better with a different ligature for each hand, then superimposing them with CSS.



  20. “Apple is proposing multicolor fonts, which would let you create and embed pure vector graphics into any web page. Its first foray into this field is the Apple Color Emoji font”

    AFAIK, Apple Emoji is a bitmap font, not a vector font. I didn’t dig enough in the color font extension to know if it supports vector font though.

  21. Font symbols are great and I use them a lot. I have noticed that if using PUA (unicode) characters of your own, on an iPhone it’ll swap out your own font for the Emoji characters (if they’re installed). Only font pack I can get to override this is FontAwesome, but can’t for the life of me work out why! Embedding the woff as Base64 seems to help, but only sometimes…any ideas?

  22. I’ve created the appearance of a multi-color glyph by using two elements. Simply negatively position the second element and set its z-index value to a number that’s higher than the first element. For example:

  23. I’ve been designing dashicons for and the MP6 plugin. One of the biggest challenges is making sure icons align to the pixel grid. -webkit-font-smoothing:antialiased goes a long way toward ensuring crisp icons on most devices; however, FireFox just doesn’t get font smoothing right.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA