I Love Typography

The Font-as-Service

When Johno first asked me to write about Typekit, I jumped at the chance. I’d received a beta invite to try out the service about a week before, but deadlines had got in the way of actually getting round to it. Now I had the perfect excuse to have a proper play, create a test site, and immerse myself in the technology that got the web design community frothing at the mouth when it was announced a couple of months ago.

However, as I started to experiment with Typekit, I realised that the really interesting thing isn’t the technology itself: it’s what Typekit — and other services in the same vein — mean for the way we experience type on the web. And I’m not talking about it from a user’s perspective, where they get to see the end results of using a variety of typefaces, but from the web designer’s perspective: the way in which we’re going to be using and paying for fonts.

typekit web fonts service

Let’s get some of the nitty-gritty out of the way first: if you’re unfamiliar with Typekit, there are plenty of blog posts out there that will get you up to speed very quickly. A logical place to start would be the official release announcement on the Typekit blog. Done that? Jolly good. Now you can peruse the various opinion pieces: Andy Clarke offers a very thorough walk-through of the service, and Mike Davidson examines (among other things) the question of Typekit’s compatibility reach. Because of these posts (and others, of course), there seems little point in me repeating the content here. However, it’s worth noting some of the details, because it’s in the details that Typekit differs from the other solutions gradually coming out of the woodwork (more on them in a minute). The biggest detail that detractors seem to be focusing on is that its delivery method relies on Javascript; not for the font display, of course, but for the domain authentication. Naysayers point out, therefore, that no font replacement will happen if Javascript is turned off (although it’s debatable how much of a concern this actually is) and it also means that it takes a while for the correct fonts to appear while the Javascript loads; an effect often seen on sites that use sIFR.

There are more drawbacks, too. While testing the service I found it simple but not necessarily straightforward, and although much of this can be attributed to its beta status, there’s an important point to consider when using Typekit: you’re defining your font stack via its online admin interface — not in your own CSS files. For me, this was the moment I really developed my doubts about the service, since that kind of separation feels very unnatural to me and acts as a major disruption to my workflow. And I won’t even go into some of the specificity issues this can arise, except to say that you should ensure the Javascript links appear after your stylesheet links, lest you want to screw up your font stacks completely.

To jump back to Typekit’s positive features, however, one of the most overlooked features is that it offers a fall-back for Internet Explorer by serving up an .eot file. Why this is important is because it simultaneously solves two major problems: the availability of multiple typefaces and an integrated delivery method that copes with cross-browser (in)compatibility. Briefly put, it means @font-face is more readily available on IE than it has ever been before because we designers no longer need to worry about all of the fiddly workarounds. This is great news for everyone.

But what about the Typekit alternatives? There are some to get very excited about. Take Typotheque’s bespoke solution, for instance. The foundry have released their own alternative to Typekit and Andy Clarke has a thorough write up of that, too. One key difference is that the authentication is done via PHP instead of Javascript, which is sure to appease those who’ve criticised Typekit on that point. But let’s not forget that this is a foundry-specific solution, and I agree with Andy that it’s sure to pave the way for other foundries to do the same; it makes a lot of sense (to them) to create their own delivery solutions and maintain control, but it’s possibly not the best solution for web designers who have to jump between a variety of systems and pricing models. Wouldn’t a standardised system be better? Haven’t the last few years of web design practice taught us that unification far outweighs the benefits of proprietary solutions?

typotheque web fonts service

Of course, it takes a while to reach one unified model and firstly there’s the small matter of fighting it out in the web design community’s playground. The most successful model will be the one with the biggest support from the community (and funding), and ideally it’ll be one that supports multiple foundries. So let’s consider Fontdeck: another multi-foundry solution, the development of which the Typekit guys will no doubt be watching with eagle eyes. Little is currently known of this mysterious creature, but the really exciting stuff, in my opinion, is the people behind it. Spearheaded by Jon Tan and Richard Rutter — and behind them the funding and support of Clearleft and OmniTI — it’s hard to imagine how this could go wrong from people who have already done so much for bringing solid typographical learning closer to the web design masses. Unlike Typekit, and similarly to Typotheque’s service, authentication will not be done with Javascript, and the word on the grapevine is that we’ll be able to work with CSS in a way that’s closer to our regular workflow. If this means something like putting a Fontdeck-generated font stack directly into our own stylesheet, then this, for me, will be a very major advantage.

Rumour has it that the Fontdeck team are also considering free support for rare script typefaces, providing a way of getting these lesser-used languages on the web, where currently they are invisible. It’s a noble cause and a great example of why proper typography on the web is more important than just pleasing the tastes of us poncey designers.

fontdeck web fonts service

With Clearleft handling the UI of Fontdeck, we know it’ll look great and have a strong focus on usability. With OmniTI handling the security, we know it’ll be as tight as a safe. The company’s track-record in online security is flawless, and with reliable sources claiming that Typekit’s security has already been hacked with relative ease, it’s natural that foundries will be more interested in signing up with a provider that can guarantee the safety of their fonts.

And make no mistake: this is what it really comes down to. A very large part of @font-face’s painfully slow adoption has been down to the font foundries and their concerns over font piracy, and rightfully so. Microsoft’s EOT format in its current state is far from ideal, but because of its potential to offer DRM, it’s the format that foundries have been happy to support, albeit half-heartedly. Now, with services like Typekit and Fontdeck, foundries finally have a reason to embrace type on the web: to open their product to a whole new audience without fear of their typefaces being stolen by anyone adept enough to click ‘view source’. Unfortunately, though, the pricing structure of these new services is still a mystery. With Typekit already in public beta, it’s likely that we’ll find out sooner about its price plans than Fontdeck’s, but right now all we can do is speculate. Undoubtedly the various services will price themselves competitively, but there are so many concerns that go way beyond the service itself: ultimately, with large foundries’ support being such a huge factor in the success of any given service, the price has got to be right for the foundries, not just the service providers or consumers.

And it’s not just a case of deciding on a figure, either. The choices of pricing models are potentially endless. Do you charge the user (that is, the web designer) per typeface? Per family? Do you offer a font purchase with an extended license for web use? Do you charge a subscription for a certain amount of service? Do you charge by the quantity of typefaces needed (5 families for $X a month, 10 families for $X a month, etc.)? Do you offer some for free and reserve some weights (or even glyphs, like ligatures) for paid customers? With the amount of questions that need to be answered and the the amount of question-askers who need to be appeased, I wouldn’t wish that kind of decision making upon anyone!

But, whatever the details of the exact services that end up being offered, one thing will be true: unlike ever before, where previously we had only purchased a font as a closed, finite, singular product, we are now entering the age of the font-as-service: where the font becomes synonymous with web hosting, mobile data plans, and movie rentals. No longer fixed, fonts will be borrowed, subscribed to, removed, expanded upon, and provided on-the-fly.

In his comment on Mike Davidson’s post, Jeff Croft raises the important question about the reliability of the service; not from the view of security I mentioned previously, but from the view of scalability:

When Doug Bowman decides to implement Typekit on Twitter, will Typekit go straight to hell, ruining it for the rest of us? Will we start seeing Typekit-powered sites hanging as we wait for the Javascript bits and font files to load?

With font files being delivered by third-party services, it’s a big concern, and another reason I feel reassured that a company like OmniTI will be looking after the infrastructure behind Fontdeck.

I praised Typekit when it was first released, and although we won’t know what the best solution will be for quite some time, I stand by my original message: it deserves praise because it was one of the first solutions to a long-standing problem; it got out there and said, ‘we can do this,’ when most other people were content to sit there and complain about it. But really this isn’t about what Typekit does, what Fontdeck does, what the various bespoke foundry solutions do, and how each of them does it better or worse than the other. Nor is it about the specifics of formats like .ttf, .otf, or the recently-proposed .webfont (which was summarised very neatly in Johno’s recent post). It’s about how service-based models are finally allowing typography to grow up and take its rightful place on the web.

Are we just hacking away to find a solution that satisfies our demands until a workable standard like .webfont or WebOTF is eventually approved and we can all hold hands and sing songs? Probably, yes. But as Mike Davidson said, “the entire world wide web is a hack.”

Elliot Jay Stocks is a designer, illustrator, speaker, & author of Sexy Web Design.


  1. thanks, nice info.

  2. That’s a useful summary, Elliot with some nice signposting for what’s to come.

    Look forward to your views on developments by the time you come to Sydney. Cheers.

  3. The article is tagged with ‘EOT Lite’, but doesn’t mention EOT Lite as an alternative.

  4. Tor
    My fault with the tag. Now reads ‘EOT’. The joy of auto-complete :)

  5. Hehe, I see. I would still like to hear yours and Elliots opinion on the EOT Lite alternative :)

  6. Just to clarify a bit on CSS stacks in Typekit: one of Typekit’s options will be to configure the typefaces from your own CSS. Creating a stack or adding selectors on Typekit’s Editor is just one way to use typefaces, but the API will allow for you to make declarations in your CSS as you always have.

  7. Elliot,

    Thanks for the article - an interesting read, although it does come across a bit like you are touting Fontdeck over Typekit, which is a little unsettling as one hasn’t had any information released about it at all, and the other is still in closed beta.

    I’m sure this wasn’t necessarily your intention; but it may be worth reminding people that Fontdeck is likely to have limitations in a similar way to Typekit once it is released - it’s just we don’t know about them yet! As you say, the whole web’s a hack, and these services are really no different.

    Having said that, it really is exciting that these services are finally becoming a reality.

  8. Mono

    Thanks Elliot for throwing (again) some light over this complicated issue… Typo on the web that is.
    I totally agree with you about the actual value of Typekit, and I can’t wait to know something more about FontDeck… to see how much of an alternative to Typekit it will get to be.

    But… I can’t help thinking that they are still NO SOLUTIONS to the big problem. From my point of view foundries are fighting a war not worth fighting. And solutions like the ones you mentioned will succeed (in a major scale) only if they manage to keep prices really low and their services integrated to web hosting companies.
    For example: I would be able to convince a client to spend u$250 instead of u$200 a year in hosting if that will let them use their institutional font.

  9. Really enjoyed this article. I’ll admit, I have been sort of just “observing” as fonts on the web begin to change, but now feel compelled to actually play around with these options a bit.

    Nice roundup.

  10. @mono “From my point of view foundries are fighting a war not worth fighting.”

    Agreed - get with the times and stop worrying about piracy! Technology changes, and you have to adapt or you get left behind.

    The record industry (and music) is still around despite these new-fangled ‘cassette tapes’ and ‘mp3 players’


  11. I’m surprised that you didn’t mention Kernest.com, a type service that already works and has dozens of free fonts available for use, along with my Downturn Family for commercial licensing. Everyone else is issuing press releases and running private beta tests, but Kernest is already up and running and ready to license commercial type.

  12. Willy Gunther

    You probably shouldn’t give the impression that Fontdeck will be hack proof. It will be hacked in short order just like Typekit was. The difference is that Typekit (and I think they addressed this on their blog) isn’t trying to be hack proof. You should probably research your sources a bit more.

  13. Excellent write-up, Elliot. I’ve been too caught up with personal projects and work this summer to do anything with Typekit…and hadn’t heard anything about Fontdeck. I feel much more caught up now and look forward to experimenting with these services, especially Fontdeck.

  14. Type foundries are fighting a war? This is news to me.

    All of the foundries I know, which is essentially all of them, have a very realistic understanding of how things are unfolding. We’ve lived with piracy for decades, and I don’t know anyone who thinks it’s possible to get that particular genie back in the bottle. What we’re interested in doing is finding ways to allow fonts to be used online, ways that are fair, practical, and affordable. As Elliott points out, that’s challenge enough!

    What we’re also doing is working with browser makers to improve the underlying technology. We’re concerned about how everyone’s going to react when “a font” adds 160k to the weight of a page (make that 640k if you like bold and italic), and what this will mean to mobile users especially. We’re mindful of the interplay of operating systems, browsers, rasterizers, and font formats, and eager to make sure that fonts look as good on screen as they always have in print. But most of all, we’re trying to take this opportunity to make sure that whatever standard is adopted is one that’s forward-thinking. There’s a specious debate about “OpenType or EOT?” online, which is a little like asking if you’d rather have JPEGs or GIFs. What everyone needs is both, and PNGs for that matter, which is why some of the most thoughtful people in the industry (representing Mozilla, TypeSupply and Letterror) have proposed a new standard, called webOTF, which will wrap *any* kind of font data. It’s a great proposal — one supported by the Typekit guys, by the way — which is focussing on the long game as well as the short. It needs everyone’s support.


    Thanks Elliot for writing a great piece about our colleagues in the industry, and paying as much attention to the big picture as the small. These are exciting times for type online!

  15. Thanks for the thoughtful overview, Elliot, and for taking the time to test our preview of Typekit.

    If I may, I’d to clarify a couple points from the article. First, regarding the use of Javascript — we’ve been working hard at smoothing out the differences in browser implementation of @font-face, and using Javascript is a great way to do that. As Safari, Firefox, IE, and Opera grow in their support for the technology, we can help designers negotiate the ways fonts load and render. As Jason mentioned above, we’ll offer an in-page API if you prefer to write markup by hand, as well as direct links to CSS, but that’s not been implemented in the preview yet. We wrote this up in a lot more detail on our blog:


    Also, it’s worth noting that “hacking” an online service suggests exploiting of a vulnerability with that service. That hasn’t happened with Typekit, Typotheque, or Kernest, nor do I suspect it will with Fontdeck. Each of these services put a collection of protection mechanisms in place — none of them perfect — to discourage casual misuse. As Jonathan mentions above, type designers and foundries have seen the effects of unlicensed use on their business for years. We’re simply trying to make it clear that font usage on the web requires acknowledgement of that licensing. Again, more detail on the Typekit blog here:


    Exciting times, indeed!

  16. Many thanks for this heads up, it’s good to know that something is being done about this web design black hole, though what permutations that takes in the end still seems quite hazy; very exciting stuff!

  17. There has never been a foundry war and there are no parallels between foundries and the record industry.

    The foundries aren’t looking to rip you off. They’re looking out for themselves. Who in their right mind would like a slow loading page be synonymous with their own product, like Skolar (regular, bold & italic)? Who wouldn’t want to be compensated for their services or products?

    Stop assuming that the web looks bad because there aren’t enough compatible typefaces. The matter of fact is, if you can’t figure out how to make a website look good in Georgia, Verdana or Helvetica you are utterly useless as a designer, and that can’t be fixed by changing typefaces.

  18. Personally I think this is the way forward as I cannot see agreement on any other method in the foreseeable future.

    However, this will only work if licensing is secure… otherwise I think we’ll be back to square one.

  19. we are now entering the age of the font-as-service

    If you were as old as me you would remember that we had this service before the age of PostScript fonts. It was called typesetting. I never had to buy a font, I just sent my manuscript to the typesetters with my instructions on how to set it and in what typeface and days or hours later (depending on the price) they sent me a blueprint or a film positive… Just like writing CSS, except that the result will be visible instantly, or almost. That’s why I look at these new services as online typesetting, no more and no less.

  20. Eric’s correlation should also indicate how this v2.0 of Typesetting Services won’t last. It may be an adequate temporary solution, but as seen with Postscript fonts, users want to do everything themselves and be in control.

  21. Chris

    “we are now entering the age of the font-as-service”

    Would anyone like to bet on how fast this age will pass?

    The problem is that while the foundries and those offering such services are understandably keen on this idea, it’s obviously going to fail horribly in practice. No-one wants to have their web site at the mercy of a third party supplier, and no-one wants to be paying arbitrary fees indefinitely just to keep things up and running. Even if designers would accept this – and I don’t for an instant believe most would – there is no way you’re going to sell this to a typical client, particularly anyone who doesn’t care about the intricacies of font licensing but does know that you managed to use different fonts on the last web site you designed for them.

    At screen resolutions, to an untrained eye, there really isn’t that much difference between fonts at body text sizes. There are already more than enough fonts that are fine for use as body text and that are already freely available without any ongoing risk or cost. Indeed, these fonts are often more suitable than the expensive alternatives anyway: during a little private experimentation, exactly none of the expensive commercial fonts I’ve bought rendered acceptably well at body text sizes on any platform I have access to, while standard fare like Georgia, Verdana, Arial and Calibri all looked much better. So there’s never going to be a really compelling case for using @font-face for body text outside of specialist contexts, even if any foundry wants to spend the time hinting its fonts to display better in small sizes at screen resolutions, which would presumably be rather expensive.

    For more specialised applications such as headers, navigation areas and pull quotes, interesting typography is more effective and makes a difference to a casual viewer. But for these more specific applications, designers can still render any font to an image format and/or use tried and tested image replacement techniques for SEO and accessibility purposes instead of adopting @font-face. It’s a bit of a pain, but that’s never stopped us doing it so far when the effect was worth the effort.

    Bottom line: I just don’t see an upside to using fonts as a service that is anywhere close to beating the downside for most potential users. I believe the whole font-as-service idea needs to die, so we can get past it to a realistic pricing/licensing model that more than five people will actually use.

    Yours respectfully but telling it like it is,

  22. Bert Vanderveen

    Rob writes: “…but as seen with Postscript fonts, users want to do everything themselves and be in control.”

    Which of course can already be done, with the side effect of not being scalable/searchable/changable. Type as image has been the norm for ‘designed’ webpages for years.

  23. @Bert
    Yeah you are right… but I was specifically speaking of users being able to host and serve up their own fonts dynamically (easier than with sIFR etc).

    I am of the opinion that if designers had the choice to either 1) license a typeface, host the font files on their website, and render their site in said typeface, or 2) pay a subscription service for using remotely hosted fonts – I am guessing most will choose to license a “real” product and hosting it themselves.

    I could very well be completely wrong about this though. It is just my thoughts.

  24. Anonny

    Thanks for writing a very unbiased preview Elliot, unlike the advertisement feeling I had when reading Andy Clarke’s preview. He really needs to get his nose out of their butt.

  25. One question I have yet to see answered is where existing licences will be valid. Not actually *owning* the font files themselves means that creating Photoshop comps for the client is going to be costly — won’t we have to buy the font twice — once as an offline licence and another through Typekit/Font Deck?

  26. Only time will tell. Great summary of the situation.

    It seems odd Adobe or another big name has not jumped into this and created a service. Maybe they don’t see a profit in it. Maybe they’re working on it. I could see a Dreaweaver font selector tool similar to selecting a song from the iTunes store.

  27. Fontdeck has my vote for the logo alone, although I do like Typotheque’s name. Regular CSS support without messing around with JS is a bonus!

  28. I’d like to second James Puckett’s recommendation that you look at Kernest.com. It’s up and running and works great. (I’ve written a tutorial for using Kernest fonts on my blog (see http://bit.ly/bjT4u)

    I’d love to beta-test and document the rest of them myself!

  29. Thanks for your thoughts, everyone. And what a huge honour to have comments from Jonathan and Erik — thank you, gentlemen!

    Jason and Jeffrey: I apologise heartily if this came across as sounding anti-Typekit. This certainly wasn’t my intention. I really appreciate you clarifying the point about the font stacks and I’m so excited with the way Typekit is going. You might be interested to read my latest post:More reasons to get excited about Typekit.

  30. Wow! Great post. I wasn’t aware of any of these solutions. It is a great day for the web now that this is getting the attention it deserves. For too long we’ve remained stagnant with the same typical font stacks while javascript and CSS improvements and adoption push us forward.

  31. Designers

    Pushing looks forward with DRM as the backend. People upload images to the web, and expect their designs not to be stolen, HTML/CSS/JS/images are all the same. Why is the solution something that should be obfusticated just for fonts? This isn’t a solution, this is the hack. The solution exists and the way to use a font is through the proper CSS methods, and licensing fonts you don’t have a license to. The same as it always has been for images.

    I concur with the final synopsis, but I personally I can’t wait to see the end to all of this SIFR/font replacement lark.

previous post: Calluna — a text typeface with flow

next post: The making of FF Duper

May Fonts April Fonts March Fonts February Fonts January Fonts December Fonts November Fonts October Fonts September Fonts August Fonts July Fonts June Fonts May Fonts April Fonts March Fonts February Fonts January Fonts January Fonts November Fonts October Fonts September Fonts August Fonts July Fonts June Fonts May Fonts April Fonts March Fonts February Fonts January Fonts december Fonts October Fonts September Fonts August Fonts July Fonts June Fonts May Fonts April Fonts March Fonts February Fonts January Fonts December Fonts November Fonts October Fonts September Fonts August Fonts July Fonts May Fonts April Fonts March 2011 Fonts February 2011 Fonts January 2011 Fonts December 2010 Fonts November 2010 Fonts October 2010 Fonts September 2010 Fonts August Fonts July Fonts June Fonts May Fonts April Fonts March Fonts February 2010 featured fonts December Fonts November Fonts October Fonts September Fonts August Fonts July Fonts June Fonts May Fonts April Fonts March Fonts February Fonts January Fonts December Fonts November Fonts October Fonts September Fonts August Fonts July Fonts June Fonts May Fonts April Fonts March Fonts February Fonts January Fonts December Fonts