The resurrection of downloadable Web fonts

Despite it being in the CSS 2 specification from 1998, downloadable fonts specified with the @font-face at-rule never caught on. The main reason was that Microsoft and Netscape chose to support different font formats, neither of which was in wide use. I remember reading about it at the time and quickly abandoning it due to the problems with cross-browser support. As did most others, it seems.

However, that may be about to change. As reported in Downloadable Fonts, recent nightly builds of Apple WebKit (not the normal nightly build but a feature branch) support @font-face rules with TrueType fonts. The browser will download the font file you specify and use the typeface it contains just like any other.

A thorough description of the @font-face feature, with plenty of examples, is available in Håkon Wium Lie’s article CSS @ Ten: The Next Big Thing, published at A List Apart in August this year.

When I first read the article I thought “Nice. But I want to see it in a browser before I get too excited.” Well, since WebKit now supports @font-face I decided to play around with it a little and it seems to work rather well.

The CSS that loads a custom font looks like this:

  1. @font-face {
  2. font-family:"MyCustomFont";
  3. src:url(MyCustomFont.ttf) format("truetype");
  4. }

You can then use the name you specify in the font-family property in other CSS rules, like this:

  1. h1 {
  2. font-family:MyCustomFont;
  3. }

The syntax is described in Font Descriptions and @font-face in the CSS 2 specification.

There’s both good and bad to downloadable fonts of course. As with all features that can be misused, this will undoubtedly be misused. There will be designers who are too excited about being able to use just about any font to remember that text is useless if nobody can read it.

On the other hand, good designers will be able to use this to render headings in beautiful and highly legible typefaces without causing any accessibility problems. And once all mainstream browsers support downloadable fonts we will no longer need to use hacks and workarounds like bitmap based image replacement or sIFR.

To summarise my feelings about this, as someone with a background in typography I can see how useful this can be, though I do worry that many will not be able to use this tool responsibly. Then again, that applies to most tools.

Posted on October 9, 2007 in Browsers, CSS, Typography


  1. Could the .ttf file be (or contain) a virus? I would feel better if the file was served from a trusted depository.

  2. Hmm, this is probably not a good idea. What about those who buy fonts and use them? Will their readers get the font for free or how will this work with copyright?

    The virus thing is a problem too I guess..

  3. My only worry about this is that all the embeddable fonts will have to be protected in some way, as I am pretty sure there is no way anyone would want to give away expensive fonts.

  4. Are there copyright issues involved in the use of fonts this way? Is it fine if the file stays on the server?

  5. This is great for web typography. Do you know why they choose truetype and not opentype?

  6. This will never, ever, catch on. People don’t want to navigate to a web site, get a “Download something” dialog in their face, just to see a pretty font. Some people accept it for Flash if it’s something they really want to see, but I would never suggest this approach for the desired typeface.

    And, besides, don’t we want users to be more wary of all crap they download while online, as opposed to this? Content it king, not some Art Director’s desire to have the coolest serif font available…

  7. I have to add: of course I do respect the wish to have a suiting font with the rest of the design. It’s this particular approach I’m against.

  8. It’s strange, there’s been quite a muted reaction to this news; the main objection seems to be that there will suddenly be a rash of font thefts!

    With some judicious use of Google you can already find many licensed fonts; I just found Helvetica easily. And if you have sufficient knowledge to search source code in order to find font information, you are capable of using Google to do likewise.

    Instead of looking at this as a challenge, font foundries should look at this as an opportunity; license fonts for use on the web at a cheaper price than for print, I bet they’d see a rise in sales.

  9. @Robert Nyman: Where did you get the idea that the user will be prompted to download the font?

    Do users get prompted to download images, JavaScript, or CSS? The same is for the font. It’s a seamless effect. The user will have no idea that they’ve just downloaded a font.

    As far as I’m concerned, this “approach” is as good as any and I’m all for it! (obvious copyright issues aside)

  10. October 9, 2007 by Lode

    @Robert: of course your browser will just download the font in the background without you needing to give permission. See reply above.

  11. Ian and Lode,

    I don’t think the comparison to JavaScripts, images etc stands. At least, that is, because it was my understanding that the fonts would be saved on the computer and consequently available to all other applications, as opposed to other included files.

    And if that is true, who wants seamless downloading of something that affects your entire operating system?

    On the other hand, if this is only available to the web browser, and saved in its cache or something similar, it’s a totally different story.

    But, I still find it a tad unnecessary to write code to specifically download a certain font. I think I personally would rather see just a larger set of default fonts available in web browser to begin with.

    And if the font specified in the CSS file isn’t available, the web browser itself could reference some central font repository to download the font in the background.

    Basically, I don’t think that the web developer should have to write extra code for downloading fonts, I believe it should be automated.

  12. Robert, there’s no such repository. If you have such a repository you also get a single point of failure and all kinds of other issues. Keeping it decentralized seems much more sane.

    I’m also not sure why you suggest that referencing a font would be anything different from referencing a decorative image. That’s not the case. No dialogs involved.

    By the way, the security concerns etc. are valid and are part of the reason this is only available on the WebKit feature-branch. It won’t be included in the next version of Safari as I understand it.

  13. About copyright: Images, music, text and many other forms of media are made available by websites on the understanding that copyright should be respected. Of course, people abuse trust by infringing on copyright, but that’s no reason to stop font files being ‘embedded’ in web pages. Any argument based on such reasoning would, by logical extension, suggest that no-one should place text or images on web pages, which is ridiculous.

    On the ‘viruses’ argument: Yes, exploitable bugs may be found in browsers which support downloadable fonts, but the concept itself is not inherently insecure. I certainly won’t be losing any sleep over the possibility of viruses transmitted through fonts.

  14. @Robert - The fonts would only be available to the browser, held in the cache.

  15. Me wonders first of all when we’ll see that in a release build of Safari. This @font-face patch has landed quite recently, and I doubt it will make its way anytime soon in a release build (with Leopard and Safari 3 supposed to be close to release). At least I hope it will be left to bake for a while in test builds.

    As for the core of the matter. I’m sure the MySpace generation will make a mess of it. Nothing new there. Reasonable designers will of course find appropriate uses for it. But there aren’t that many around.

    @ Robert Nyman (comment 11). I tested with one of the nightly WebKit builds. The downloaded fonts were nowhere to be found in the usual locations (10.4.10). They are downloaded with the rest of the page resources and end up in the Safari/WebKit cache: unavailable to other apps.

    And hopefully that is enough sandboxed to prevent ‘bad’ fonts -and their payload- to have any effect on the system. And I hope the browser will come with some UI to disable downloadable fonts, just as one can disable images or Js. (I’d have it turned off, assuming I use Safari, which I don’t)

  16. Also: from all that I’ve read, the likelihood of getting a virus or trojan from a .ttf file is very low; for example, this article puts .ttf files on the ‘safe’ list.

    Of course, that’s not to say it’s impossible; but you can potentially get infected from a .jpg file under certain circumstances, and nobody thinks of not using those on the web.

  17. If the fonts are solely available to the web browser, then I’m more open to the idea. But still, you will write code to specifically tell the web browser where to download a certain font, which I’m not sure is the developer’s problem (given that it is a mainstream font, and not exclusively designed for that certain web site).

    I do see the downsides of a central repository, but I also see it as a sort of quality guarantee. Meaning, instead of people forcing down potentially damaged font files to a user’s computer, there would be one place where quality and interoperability would ensure it was always kept up-to-date and suitable for usage.

    This, would in turn be some open source-repository, I guess.

    But, either way, I think it will be a very long time before any of this becomes reality, and that certain web browser manufacturers *cough* will take their own route, so only the future can tell…

  18. I think copyright issue could be sloved: if you buy the font, you can use it (it’s similar in print: if you buy a font you can use it in your printed media), right?

    But, yes … any solution regarding embeding TTF fonts would be great.

  19. October 9, 2007 by Emil Björklund

    I can see how useful this can be, though I do worry that many will not be able to use this tool responsibly. Then again, that applies to most tools.

    @Roger, a lot of those people would have to learn using CSS (as opposed to presentational HTML) at all first to be able to use it irresponsibly. So it might be a while. :-)

  20. I don’t think this is much of an advance. All it does is add another browser-specific approach to the Microsoft and Netscape ones already mentioned.

    If you want to pick one of the three (instead of using images or sifr or whatever), and you want the most visitors to see it, the MS version is probably your best choice. It conforms (I think) to the CSS3 syntax, and uses a special file format (easily created from a .ttf file) that only browsers can understand. Having to put your .ttf files on a freely accessible URL is a real drawback of the WebKit approach, and one that Foundries are not going to be happy with.

  21. @marc and robert: The fonts would ofcourse not be handled much different from images. Which means no download dialogs, and no more viruses than you get with your normal gif files.

  22. If the font is actually downloaded (without the user knowing) it is then a security issue and many originations would disallow that anyway.

    If it is only held in cache then it may become a performance issue.

    It sounds like a gimmick, and I believe they had considered removing @font-face in CCS 2.1. Although if they decide on a “common method” that would be some progress.

  23. October 9, 2007 by Stevie D

    Basically, I don’t think that the web developer should have to write extra code for downloading fonts, I believe it should be automated.

    I want people to have access to the images and the scripts that I choose. These should be built into every browser! Why should I have to go to the trouble of uploading and referencing the files I want to use?! How lame is that!!??!

    Don’t be ridiculous.

    If you want people to be able to use your choice of fonts, you have to make them available - just like if you want people to see pictures or run scripts. You can’t expect browsers or operating systems to have all the fonts you want, given that people have already bought the computers they own, but new fonts are being designed all the time. Unless you can find a way to beam the fonts onto everyone in the world’s computer as soon as they have been designed, you’re in a fantasy world.

  24. I was really excited by the opportunities presented with this, but I share your concerns.

    I have an additional concern, how does licensing work for such a thing? Would designers have to buy some kind of publisher type license to embed a typeface on their page, or would purchasing the face to begin with be enough?

    Either way I think this could get really interesting for the corporate site I work on. We were using sIFR for our headers, but it didn’t play nice with our security settings.

  25. October 9, 2007 by Nathan Rutman

    I’m all for it. I think we should be able to use custom typefaces for web DESIGN.

    As for the copyright issue, I heard a pretty cool suggestion at another post. The foundries themselves could fairly easily implement a service where you apply for a site key (like Google Maps), and then they could track which domains are requesting which fonts. One domain or customer per key, and then check that customer’s domains against the requesting domain to see if the request is valid.

    Hopefully that won’t happen for the $25 fonts, but it might be a nice solution for the $200 ones.

  26. There are a few joys and concerns I have with this feature:

    Joy #1: As a member of the FSF, I like the idea of custom typefaces without the need for proprietary software. I know Gnash is available, but ya’ know.

    Concern #1: Viruses? I don’t expect to see this in IE for a long time.

    Joy/Concern #2: After the thought of viruses, my next thought was with keeping licensed fonts, well, licensed. But after some thinking, I realized that any real company or design firm wouldn’t be so stupid to steal fonts. I think only nerdos & script-kiddies would be the great offenders. But then again, have you seen a website made by them (with 5px high image text)? I’d doubt they’d appreciate a beautiful serif font for their IRC or clan page.

    Also, if someone is going to steal a font, the offender may be too lazy to change the file name. If so, a Google search can solve the problem. :)

    And now, back to work!

  27. I am truly excited over this technology.

    I tested by copying an open type font ending in .ttf from the PC system fonts folder to a folder on the test site and tested it.

    I actually copied the html coding and css from the sample given in the CSS 2 specification

    It worked for me Firefox and IE6 on the pc, but didn’t work on Safari on the mac.

  28. I think it’s a great idea. I mean, almost everything has a few downsides, but that doesn’t mean you throw the baby out with the bathwater.

    People who actually appreciate good typography will probably love this.

  29. October 9, 2007 by Adam

    Is it just me, or is this not much different than hotlinking an image?

  30. Well I’d like to say I’m excited but until the major browser vendors get onboard, I see no reason too. Internet Explorer 8 is rumoured to be released in 2009-2010 and with them missing out major CSS fixes/features in IE7 I don’t see this on Microsoft’s priority list.

    I’m sticking with the many other methods of using custom fonts including the dynamic headings one I published on Code Project. I live in hope though!

  31. The only problem that I see that average good Unicode font is 100+ KB

    For example, see new MS fonts:

    Calibri - 249 KB

    Calibri Bold - 251 KB

    Calibri Italic - 271 KB

    Calibri Bold Italic - 273 KB

    Consolas - 95 KB

    Consolas Bold - 96 KB

    Consolas Italic - 100 KB

    Consolas Bold Italic - 106 KB

    It seems that for now this technology can be useful if applied only for site headers for example, not for all body text…

  32. Fonts on the web? It will be 1996 all over again!

    Then again, if it actually catches on, it will help further the gap between professional designers and your client’s wife’s brother’s daughter’s boyfriend who is a junior on high school and only charges $300 for their whole website.

  33. Hey, it makes me feel young again, when IE5 was the king of the hill and everything I did had an embedded custom font somewhere (customers were duly impressed).

    WEFT, the free (as in beer) toll from Redmond to create .eot files, had two features of interest: first of all it didn’t allow you to convert a .ttf into an .eot if the font’s embedded licence didn’t allow this kind of use, second it allowed you to incorporate a subset of characters instead of the full monty. This last was a good thing(TM): font files were not meant in origin to be sent down the wires and they had a disturbing habit to grow to unwieldy sizes - here goes all your CSS and script compression, eaten by a single font.

    It worked as long as you used the font to decorate parts of static pages - you just emmbedded what was needed to render headers and such; when PHP came along, with user supplied content, only the full set of characters would do. If your users happened to use something out of ASCII range, you’d have to embed a fair deal of Unicode gliphs to be safe (think sending ARIALUNI.TTF down the intertubes - on my box it’s 22.7 MB!).

  34. October 10, 2007 by Henry

    But what’s to say that the browser will even let the user see the font file - or even ask permission to download it?

    By the same token, we should all be worried that any image downloaded from the internet could contain a virus! (I know, image viruses / expolits have been found before, but they really haven’t been all that common)

    I think it would be great to let the web designers know they can just use any font they like - it would make my life a whole lot easier anyway.

  35. I’m waiting for this to work as well! In the meanwhile we are using sifr over here to replace header text with flash without drawbacks on accessibility or seo. Link below for anyone thats interested … works a treat for us!

  36. Yeah think I will do likewise and use sifr like web designer said.

  37. October 10, 2007 by Isaac Lin

    I think we can look at stock photography images for an indication of what may happen if making digital fonts publicly available for download becomes prevalent. Images on the web tend to be just good enough for on-screen display (both to save bandwidth as well as to limit other uses), and are sometimes watermarked. I think foundries may provide multiple versions of their fonts: web versions that only support lower resolutions (for on-screen display) and a limited repertoire (to limit download times, potentially several different variants covering different languages), and fully-featured print versions.

  38. I am interested in how fast the other browsers will follow Apple WebKit in this. WebKit is alone with supporting a lot of neat CSS3 features (most of them mentioned earlier here by you, Roger), but as this is part of the CSS2 specification, one maybe can be optimistic.

  39. IE discontinued support for WEFT fonts with IE 7. I doubt we’ll see an implementation of the CSS 3 Web Fonts module in IE 8, so it’ll be a few years until this is widely available.

    The problem with font licensing isn’t necessarily using a font without having paid the fee, it’s putting it up on a website for anybody to download – also known as distribution.

    The size of the font files is another important point.

    All that said, and taking into account that I’m pretty biased I do think this is a great development. sIFR is a hack. A cool hack, but a hack nonetheless.

  40. October 10, 2007 by bryane

    Interesting that the focus here appears to be on licensing. My chief concern, as someone with (slightly) impaired vision, is whether the “pretty fonts” that are chosen for a web page will render that web page unusable.

    The same problem cropped up with colors; I now use a web browser that allows me to override font and background colors so that I can actually see the pages.

  41. October 10, 2007 by Stevie D

    The only problem that I see that average good Unicode font is 100+ KB

    Yes, and how many sites have headers or splash pages that exceed that? Quite a few!

    I would hope that browsers would have an option to turn off font downloading, so that users on dial-up wouldn’t have to wait while 100K of fonts came through the wire, but still allowing those on broadband the full whizzy spectacle.

    It seems that for now this technology can be useful if applied only for site headers for example, not for all body text…

    Do you mean that the browser would only download the characters required? I think it’s more likely that they will download the whole font, so it wouldn’t make any difference whether you’re using it just for the header or for the whole of the body text.

  42. October 10, 2007 by Stevie D

    The problem with font licensing isn’t necessarily using a font without having paid the fee, it’s putting it up on a website for anybody to download – also known as distribution.

    And why would that be any different from now? There’s nothing technically or physically stopping me from uploading a .ttf file onto my website and encouraging users to download and install it before viewing the rest of the site.

    What this mechanism allows is for licensed use of fonts, whereby the fonts are stored on the site of the owner/publisher, and will only be served when requested by an approved (ie licensed) site or domain.

    If you make anything available for download on the internet, you suffer the risk of people uploading, sharing and distributing it without your consent.

  43. October 10, 2007 by Rodney Millington

    I guess some people do not do further reading. 1st. Taken from W3C (

    15.3 Font selection

    The second phase of the CSS2 font mechanism concerns the user agent’s selection of a font based on author-specified font properties, available fonts, etc. The details of the font matching algorithm are provided below.

    There are four possible font selection actions: name matching, intelligent matching, synthesis, and download.

    font name matching In this case, the user agent uses an existing, accessible font that has the same family name as the requested font. (Note that the appearance and the metrics might not necessarily match, if the font that the document author used and the font on the client system are from different foundries). The matching information is restricted to the CSS font properties, including the family name. This is the only method used by CSS1. intelligent font matching In this case, the user agent uses an existing, accessible font that is the closest match in appearance to the requested font. (Note that the metrics might not match exactly). The matching information includes information about the kind of font (text or symbol), nature of serifs, weight, cap height, x height, ascent, descent, slant, etc. font synthesis In this case, the user agent creates a font that is not only a close match in appearance, but also matches the metrics of the requested font. The synthesizing information includes the matching information and typically requires more accurate values for the parameters than are used for some matching schemes. In particular, synthesis requires accurate width metrics and character to glyph substitution and position information if all the layout characteristics of the specified font are to be preserved. font download Finally, the user agent may retrieve a font over the Web. This is similar to the process of fetching images, sounds, or applets over the Web for display in the current document, and likewise can cause some delay before the page can be displayed.

    Progressive rendering is a combination of download and one of the other methods; it provides a temporary substitute font (using name matching, intelligent matching, or synthesis) to allow content to be read while the requested font downloads. Once the real font has been successfully downloaded, it replaces the temporary font, hopefully without the need to reflow.

    Note. Progressive rendering requires metric information about the font in order to avoid re-layout of the content when the actual font has been loaded and rendered. This metric information is sufficiently verbose that it should only be specified at most once per font in a document.

    end W3C quote.

    As you can see there would be no d-load dialog. I would logically think that the font would be downloaded into a temp-internet folder, just as images, js, and so on. Thus the font would not reside in the system font folder and would not be available to all application. (I should point out that a user could move the font into the system font folder thus making it available).

    As far as copyright for fonts there are many applications that will allow the designer to specify groups of fonts to activate/deactivate at the wish of the designer. Allowing him or her to switch between free fonts for web design (thus no copyright issues) and purchased print fonts for printed design). I believe that the issue of copyrighted font usage is solely on the designer. If you wish to create a font and include it via CSS2 but wish to be compensated for its use out side of the web site then don’t use it. Leave it for another section of your site. If it is a font freely distributed on the web do the homework to ensure it is truly free and if so use it.

    I personally would not use a Type 1 font for web design due to the fact that it’s intended use is for print media and that most if not all Type 1 fonts are copyrighted. To agree with some others the medium is screen! As a designer we are all limited to our choice of medium and pallet. (the painter at his easel?) I say the more typographical control we can gain in web design all the better. Doesn’t it make more sense to use type when called for instead of an image, now you have accessibility to contend with.

    Oh and viruses in fonts - you downloaded it first why didn’t you scan it?

    Sorry to be so long winded but as fanatic on type & typography & design I could not pass by with out giving my 2 Lincoln’s worth.

  44. Copyright issues… surely if you have purchased the font them it is yours to use as you see fit.

    Can you really claim someone as distributing fonts just because they are embedded in the website. Sure, it wouldn’t be that much effort to browse the CSS and find the url for the font or to move the cached version to your fonts folder, but that is not your problem. Or is it.

    Its a tricky question.

  45. October 13, 2007 by David

    Buying a font doesn’t mean you have the right to distribute copies that can be installed on others computers. You have to check the license of the particular font for just what you can or can’t do.

  46. Unless you are one of the few very talented designers out there who are also experts in typography, embedded fonts are a bad idea.

    But in general, we should leave typography up to the typographers.

  47. So what if you could use CSS to let the webserver render images using high quality fonts?

    • No copyright issues since the font is not downloaded.
    • Small download sizes.
    • And it is backwards compatible.

    One of those solutions includes a script I wrote called True Font Family.

    It is an alternative to sIFR or P+C DTR.

    You can see it in action on my site:

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.