Skip Navigation

Identifying the Real Issue with Web Fonts

The web design field has been all atwitter with talk of a future where web fonts are actually available. It’s like the flying car of web design, and it may actually arrive in a useful form before we know it. Even my good friend Samantha, who’s generally happy trying to do as much as possible with the choices we already have on the web, got giddy at the notion of having Mrs. Eaves available to her as a web designer.

The recent optimism centers around three recent developments: @font-face support in Firefox 3.5 and Safari, the .webfont proposal by Tal Leming and Erik van Blokland, and the in-private-beta TypeKit service led by Jeff Veen.

Long story short (as I understand it), type foundries don’t like @font-face, because it basically makes it easy to download fonts from any website that uses it. For some reason, the foundries seem to be getting behind the other two proposals.

From my chair, though, it doesn’t look like the TypeKit and .webfont proposals offer anything that really should satisfy the foundries.


Here’s the simplest way I can explain the proposal:

  • Take a font you want to use, probably in .otf format.
  • Make up a little XML file that has some metadata about the font, including some fields that define permissions. This is all in plain text.
  • Zip the two files into one, and name it .webfont.

That’s nice and all, but that’s trivial to make, and offers the foundries no protection of any sort. It simply obscures (barely) the permission table in a zip file.

If I wanted to use my favorite typeface, it would take me no more than three minutes to make a .webfont file for myself, and I’d still be able to download others’ .webfont files from their websites and take their fonts, were I a nefarious type of person.

There are lots of foundries supporting .webfont. I suspect that most don’t really understand the proposal, and think that since it was created by two folks from inside the industry, it must be everything they need.


TypeKit leverages your browser’s support of @font-face (OTFs for Gecko/Webkit/Presto and EOT for IE) via an online service and a bit of JavaScript you dump into your page.

You, the designer, effectively rent a font face for use on the site you’re designing. When someone visits your page, the JavaScript calls TypeKit, fetches a stylesheet that includes the fonts themselves embedded in the stylesheet, and applies it to your page. The font only includes characters that will be used on your page, so it’s not necessarily a complete font.

However, it’s trivial to go ahead and download the font from TypeKit anyway. Base64 encoding, the method TypeKit uses to obfuscate and embed fonts, is incredibly simple, and by simply pasting the embedded font (from, say, Firebug) into a decoder like this one, you’ll have an .otf ready to use on your local system.

How trivial? Here’s how long it took me:

Don’t get me wrong: TypeKit does offer a new and very interesting business model for type foundries, but it doesn’t offer anything in the sense of real security to foundries. As they say: security through obscurity is no security at all.

If it were just the business and licensing model that foundries were going after, they would already be offering very expensive web licenses for fonts, wouldn’t they? They can do that themselves, without a middle-man.

So What’s the Issue?

So if foundries don’t like plain @font-face because of the potential for downloading fonts, why do they seem to like .webfont and TypeKit? Is it:

  • That foundries really just want some form of barrier between the font and the user, and they expect users to heed this boundary, even if it’s only a small hurdle?
  • Foundries just don’t like the idea of an .otf freely floating around?
  • Foundries don’t really understand the proposals at all, and think they provide some level of security when they in fact do not?

I’m one of the folks who thinks that @font-face is good enough in itself, since we’ve gotten this far with raw embedding of things like images, and the stock photo industry clearly survived and continues to do reasonably well.

But I fear that although everyone is beginning to feel the momentum and get hopeful, foundries will soon come to find that these proposals offer them relatively little (TypeKit’s rental model excluded) that they don’t already have, and they’ll pull their support just as quickly.

So if downloading an .otf isn’t really what we’re trying to solve, why aren’t more foundries offering web licenses right now? Why support the .webfont proposal? Why look to TypeKit as the key to unlocking the puzzle? Is a non-proprietary EOT-like format really the answer we should be looking to?

What are we really trying to solve?

By the way, since you've made it to the bottom:

  • You should subscribe to my RSS feed here.
  • You should follow me on Twitter here.
Avatar of M. Jackson Wilkinson

I'm M. Jackson Wilkinson, a technologist, designer, speaker, educator, and writer in San Francisco. I'm the Founder of Kinsights. I'm from Philadelphia, went to Bowdoin College in Maine, root for the Phillies, and love to sing.

Entry posted from Pearson Square Apartment

Recent Entries

Diversifying Your Design Strategy

Smart consumers balance risk in their financial investment portfolios, and smart designers should consider design and product investments the same way.

Consider the Product

The best thing about product design is its inherent contradiction. The best products think of everything, but at the same time, they’re focused on exactly one thing. If you can wrangle that, you’re almost there.

Identifying the Real Issue with Web Fonts

The recent .webfont proposal and TypeKit service don’t seem to get us anywhere closer to terms that type foundries should embrace. So why are they embracing them?

Seeing the Forest for the Trees

The broader the web gets, the more specialized its practitioners are becoming. The role of the generalist is incredibly important, and we can’t keep neglecting it.

The Shackles of Simplicity

Though simplicity is the darling of the web, we’ve now long outgrown it. Life is complex, and tools to conquer life’s complexity need to instead embrace it, rather than ignore it.

View all entries


  1. Jackson,

    You're absolutely right - many foundries are generally uncomfortable with installable OTF files being openly served on the Web. We've spoken to dozens of them, and they also realize that there is no such thing as security and protection of online digital assets. Most are interested a simple mechanism for license discovery, and enough protection to avoid casual misuse. That's what we're trying to do with Typekit and we're getting a lot of traction on that.

    It's also worth noting that the files you've download aren't useable as an installable font without opening a font editor and recombining the glyphs. Yes, you could do that step as well, but honestly, there are easier ways to steal fonts if you really want to.

  2. Wow. Somehow I would have assumed that there would be a solution that's more, I don't know, 'protected'. I almost feel bad for the guy who created Typekit. Thanks for the video - you really did do it in under 2 minutes, and that's only because it took that long to explain it.

  3. Ah - I see; you're more about protecting against casual misuse. I actually appreciate that, Jeffrey. By not treating us like jackasses, we're more likely to not be jackasses.

    I stand corrected.

  4. I have one more question to ask, and may very well be due to my non-designer ignorance. What is the likelihood that a font protection scheme could be created without the support of browsers? Things like DRM in music only really worked (and sucked for the end-users) when the players (iTunes, et al.) supported “decrypting” the audio files. On top of this, each player and corporation had a different scheme which rarely would be licensed to others.

    Encrypting/decrypting for stock images doesn't really work because a screenshot can simply be taken of the displayed image. So, I'm glad it was never attempted. Can the same be done with a font (e.g., screenshot turned easily into .otf)?

    Great article, as always.

  5. @Jeffrey: Thanks for the response. I suppose that if I made a page with all the Latin-1 (or an even wider array of characters) and rented a font via TypeKit, TypeKit would divide characters among multiple fonts and rely on the cascade? It'd probably be pretty straight-forward to create a script that took multiple fonts and combined their glyphs, but it's probably not a big concern to you guys.

    @Tony: I don't think any web font proposal could be successful unless it worked natively in browsers without any add-ons. Any DRM scheme of substance would require some sort of add-on or support in a browser, and only EOT is currently implemented (in IE4+).

    The goal for the whole thing is to create a scheme that is easy for web creators (designers/developers) to implement, easy for the often very small font foundries to produce, and ideally supported as widely as possible, apparently with a small hurdle to annoy potential evil-doers. DRM only strengthens that last need, and nearly destroys all of the others.

  6. Sooo… you steal a copyrighted font and then post publicly about it. You aren't a very good thief.

    You're missing the point, what Typekit does isn't supposed to be impenetrable. It's supposed to put up a barrier to casual piracy. Yes, you can make a script to download, convert, and reconstruct fonts, but it's one of the least effective ways to steal fonts because it sounds like most times Typekit fonts won't contain the full character sets. A font isn't that useful if it doesn't have numbers or is only punctuation. Plus it becomes widely public that you stole something. It wouldn't ever be a case of “I didn't know any better”.

    I think one of the best advantages of a system like Typekit is that it isn't tied to a single format forever. If all the foundries get behind one format and it becomes easy to game, we're right back where we started. Typekit's solution could be flexible and adapt after it's already out there.

  7. This is really helpful. I'd been trying to figure out how these relatively minor roadblocks were satisfying the font vendors myself, and between your post and Mr. Veen's answer, it makes a lot more sense, even if it's a little less than completely logical.

    It's clear though, that some folks (like Steven Maverick) didn't really get your post. Thanks for it!

  8. Unfortunately font creators are under the mistaken belief that they will be protected by one of the proposed schemes (.webfont or EOT Lite), and also believe the rumors that a new format would be implemented quickly (in reality I’d say 3+ years for EOT Lite and 5+ years for anything else to widespread enough to be usable), or indeed at all (Mozilla opposes EOT Lite). You can’t go past the fact that @font-face works today (with a bit of IE .eot pain), has great fall-back, and will have widespread support in a year tops.

    Luckily with services like Typekit, Fontdeck and Kernest, plus a growing number of free appropriately licensed fonts, I suspect it’ll soon be a non-issue. Web designers who want to use fonts will find a suitable @font-face font and use it. Font creators who choose not to license their fonts for @font-face use (either directly or via a service) will just not get any money from these web designers. It’s a valid choice, although I expect one that some will regret in a few years.

    Certainly if you’re a young font creator looking to make a name for yourself and some cash too, this has to be one amazing opportunity!

  9. M. Jackson, Thanks for this posting. I'm trying to catch up to new trends in web design and it's endless.

  10. Generally I don't read post on blogs, however I would like to say that this write-up very forced me to check out and do so! Your writing style has been surprised me. Thanks, quite great post.

  11. This stylish keychain makes it simple to carry with its super bright LED light it also can be employed for emergency illumination. This word could be practical to inspection from the distance by using electronic apparatus. For children, it is usually not a good idea to allow them make use of high priced, 12 megapixel camera.

Add a comment

Real names, svp.

Required, but I won't use it for anything, promise.

It'll get checked to make sure it's legit, but it's optional.

Don't be mean, don't be a tool, and make a contribution. Use markdown.