LearnGetting Started with Typekit


writes on July 30, 2009

The easiest way to use real fonts on the web

[Editor’s note: Dan Cederholm will be teaching Progressive Enrichment with CSS3 at FOWD NYC.]

Back in May Jeff Veen (previously of Adaptive Path and Google) announced Typekit, a subscription based service that will allow web designers to use licensed fonts on their own web sites. As Jeff himself explains:

“We’ve built a technology platform that lets us host both free and commercial fonts in a way that is incredibly fast, smoothes out differences in how browsers handle type, and offers the level of protection that type designers need without resorting to annoying and ineffective DRM. As a Typekit user, you’ll have access to our library of high-quality fonts. Just add a line of JavaScript to your markup, tell us what fonts you want to use, and then craft your pages the way you always have. Except now you’ll be able to use real fonts. This really is going to change web design.”

Introducing Typekit

We were lucky enough to have been given a preview invite to Typekit and in this mini tutorial we will be taking a quick look at how to actually implement Typekit in our own demo page.

Step One: Create an HTML Page

Screenshot of demo page

To get started I simply created an HTML document with a few simple CSS rules, an H1, an H2 and two paragraphs of text.

View the demo page

Step Two: Creating a Kit

Typekit kit page

Next it’s time to head over to the Typkeit web site to create our “kit”. This kit will ultimately produce a JavaScript file which will contain the necessary code and fonts to render our chosen typefaces. The two fields are: Name (you are allowed to create a number of kits) and Domains. Each kit is individual and related to a particular domain or domains, e.g. I could use the same kit on both carsonified.com and keirwhitaker.com.

Step Three: Choosing Your Fonts

Typekit homepage

Once we have created our kit it’s time to select the fonts we want to use on our web site. For this demo I chose Bello Pro and Proxima Nova. Once you have selected your fonts by clicking the “add” button it’s time to launch the “kit editor”.

Step Four: Configure your Kit

Typekit editor

The Typekit Editor allows you to apply your chosen fonts to any HTML element, class or id. In the example above I have selected the Bello Pro font (highlighted in green) and specified that I would like it to be applied to the h1 and h2 elements as well as any element with a class of “keir”. You can also target any element by id, for example I could have added #header which would result in the text in my #header element being rendered in Bello Pro.

Kit editor - weights section

Unlike Bello Pro the Proxima Nova font has additional weights and styles associated with it. Typekit allows you to choose which ones you would like included in your kit., however adding additional weights and styles will increase the size of your kit considerably. For the demo I have just selected “Regular” and specified that I would like all “p” elements to be transformed into Proxima Nova.

For non @font-face enabled browsers you are able to specify “font fallbacks”. For our demo I chose the default “sans-serif” but you could be more specific. Once you have specified your selectors, weights and styles and CSS stack settings it’s time to “Publish” your kit. Due to the fact that all kits are unique it may take a few minutes before it is ready to be served from the Typekit servers.

Step Five: Adding the Kit to your Web Page

Kit editor settings

The last thing we need to do is add the JavaScript that references our kit to our web page. To do this we simply click on “Kit Settings” and copy the code from the pop up window. This window will also allow you to edit any of the settings you specified in step one. Finally it’s time to head on over to your HTML file and paste the script references into the <head> section of your HTML page.

Step Six: Preview your Web Site

Demo page

As you can see from the screen shot the headers and paragraphs are now styled in our chosen fonts.

View the demo page


Typekit was very easy to use and the interface is very intuitive. My kit was relatively small and as a result the transformation of the fonts was relatively instant, however I imagine as you add fonts to your kit initial loads may take longer. There’s no word yet on the pricing model for Typekit but if they get that right I have no doubt that the service will be extremely popular.

Further Reading

There are a number of great blog posts on Typekit and related @font-face delivery services, here are some must reads:

[Editor’s note: Dan Cederholm will be teaching Progressive Enrichment with CSS3 at FOWD NYC.]


Learning with Treehouse for only 30 minutes a day can teach you the skills needed to land the job that you've been dreaming about.

Get Started

53 Responses to “Getting Started with Typekit”

  1. I have developed small WordPress plugin to add Typekit font easily to your blog.


    Hope you like it. 🙂

  2. Must complement the writer on compiling this post. Good presentation and high on content. Chheeeeerzzzz.

  3. Great post. I’ve been looking for an easy way to use new fonts. It’s disappointing to hear that it may not be compatible with newer versions of Firefox. Hopefully this will be addressed soon.

  4. I’m still not sold on Typekit. I can see where it helps with the legal issues surrounding @font-face implementation, but it’s not the web design revolution it’s being cracked up to be, and is actually a little misguided in my opinion.

    Essentially I believe that if you are serving up content to your users on the web, you need to accept that they are inherently going to have access to that content. If we serve up a CSS file (or an image, or a JS file) to the user’s browser, the user is of course going to have access to that file, because you sent it to them!

    CSS and fonts essentially perform the same function – they are used to style content. However with Typekit we are saying yes, we still want to serve up something that the browser will use to style some content, but for legal reasons we don’t want a human user to be able to access that styling information, because they may take it away and apply it wherever they want.

    I feel this is contradictory to how the web works – we serve stuff up to people’s browsers that we are comfortable with them seeing, and stuff that we don’t want them to see stays server-side. Typekit goes against this paradigm – it serves stuff up, but pretends it hasn’t, or does it in such a way that a human user won’t be able to interpret and reproduce it.

    In practice, my big issues with it are the big Flash Of Unstyled Content I get when loading the page, and the fact that there are still going to be inconsistencies with how the fonts are displayed across browsers and systems. I get the feeling from the comments I’ve seen that many of our more heavily design-oriented colleagues are expecting the pixel-perfect text rendering they now get by using Flash or images.

  5. Great info. Can’t wait until I can use this in one of my designs. Though I worry about IE6…

  6. Typekit looks absolutely amazing. It looks very easy to use.

    I can’t wait to use this on one of my designs!

  7. Only works in Safari and Firefox on Windows for me. MSIE 7/8, Chrome and Opera = nothing.

  8. Hey nice, Bello and Proxima Nova! I used the same two typefaces in this example:

    This is a wonderful step-by-step, Keir. Thanks for sharing.

    • Tim, I was hoping I would see a comment from you!
      What’s disappointing is that we have JS such as cufon, sIFR, TypeSelect, Typekit, etc that force another layer of complexity onto an already inferior solution that is @fontface. Until there is a way to have fonts render smoothly without displaying unstyled first, and with a visible delay, I’m not sure I will be using this technique at all. It will be interesting to see how well it is received by web professionals and the general public, I know everyone is chomping at the bit about the using any font without having to resort to graphics or flash, but do we jump on this bandwagon or wait for the next one?

    • Keir Whitaker on July 31, 2009 at 6:26 pm said:

      Tim – the font choice was more luck than judgment but they seemed to work well together 🙂 Glad you found the article useful.

  9. I know I’m going slightly off track here (it’s still type-related), but if you were to use @font-face, could you embed fonts located above your root directory? If so, how easy would these be to ‘steal’?

    To be honest, I’m not too sure how the browsers deal with font embedding. Do they cache a local file?

    P.S. Glad you fixed Greg’s bad coding… 😉

  10. Love the idea of TypeKit, can’t wait to try it out myself… but I’m not a big fan of the font files being hosted remotely.

    I’m on a pretty decent connection (DSL, but not the fastest tier) and when loading the demo page there was a noticeable flicker of the unstyled fonts in all browsers. (And a good second or two of waiting for the styling to show up in safari).

    This is something that never, ever happens in Safari when the file is located on the same server (and called through CSS only) as Safari waits until the @font-face file is loaded until rendering any type.

    I’m not sure if it’s the javascript obfuscation or what, but something is definitely breaking Safari’s usual DOM load and render sequence. Or at least causing it to hiccup.

    I also wonder if TypeKit really has the capacity to handle hundreds of thousands (if not millions) of font requests when they come out of private beta. Google seems to handle it alright for their remote analytics .js serves, but I’m sure we’ve all seen imageshack’s bandwidth overload images, and twitter can barely keep up with remote API requests.

    I guess only time will tell…

  11. Woah!
    This looks really cool… can’t wait for it to come out?
    Any idea of a release date 🙂

  12. Typekit is maybe good idea, but in my opinion, this is really unnecessary. People can simply use @font-face element on their CSS files. Even no using javascript.

    For instance, Firefox 3.5 supports Typekit and @font-face too but IE7 supports not Typekit and @font-face too. But!, if you use Typekit in IE7 (you can check the demo on top) you must wait the rendering… And not effects at all.

    If you use basically @font-face, you can write the alternative fonts with font-family and like IE7 or using not-supported browser visitors can get the right font instantly. Why am i use extra javascript codes? I can write so many complex usability factors about this topic. I prefer always @font-face with standalone.

    • Keir Whitaker on July 30, 2009 at 2:28 pm said:

      The JavaScript approach is, I believe, mainly to do with the licensing issues around web fonts. If you reference a font source file using @font-face it’s theoretically possible that anyone could look at the CSS and grab the font for their own use.

      From what I have read this is one of the main stumbling blocks with web fonts, Typekit addresses this problem in a number of ways and makes using the fonts “legally” a possibility. More here on how and why they do it this way.

    • Keir Whitaker on July 31, 2009 at 6:24 pm said:

      The .htaccess approach sounds interesting, unfortunately I got a “Page Not Found” error when I clicked your link. Would you mind posting it again or emailing it to me [keir at carsonified dot com]. Thanks.

  13. I take it we’re all bored of Sifr now…

  14. I both like and dislike the idea of Typekit.

    I think giving people more font options is fantastic, and as people before me have said, it will change the way a lot of people design (for the better).

    The only problem for me is that it uses javascript, and therefore @font-face would be my first and only choice.

    The way I might use Typekit would be to use @font-face for modern browsers and then use Typekit to add the exact same fonts in for other browsers. The drawback to this would be reducing Typekit’s vast font library to ones with a @font-face license.

    I know I should be more excited about Typekit, but I’m far more interested in font embedding; probably due to the fact that I have js turned off by default, as I assume a lot of web-savvy people might.

    Don’t get me wrong, I’m not against Typekit, I’m just don’t think it’s the be all and end all that some people (not implying Keir) think it is. Perhaps in a few months and change.

  15. This is going to change the way we do web design. I cannot wait to start using their kit.

    I think web design needs this kind of refreshment, people are going to start getting rather creative with type based sites.


  16. Nice one for this post. Typekit looks a seriously cool bit of, erm, kit.

    Quick question about the rendering – in FF3.5 there is a height issue. Is this down to the javascript, the font, the css, or a little bit of everything?

    • Jbcarey on July 30, 2009 at 7:38 am said:

      Yes, I’ve noticed this too and as such won’t be using this one my sites…. I wonder when we will finnally be able to use font’s on ALL sites/Browsers!

      • Jbcarey & others – It’s now possible to use the CSS3 @font-face selector for cross-browser font embedding – Here’s how.

        No subscription … no 3rd-party server reliance … no JavaScript reliance … easy to use. It’s not (yet) ideal, but possible and IMO way better than TypeKit. 😉


    • Keir Whitaker on July 30, 2009 at 8:39 am said:

      Tom – It’s hard to say. What I hadn’t done in the demo was “reset” the CSS. I have changed the demos to use the Yahoo Reset and the difference between Safari and FF on Mac is very clear on this screenshot.

      I suspect it’s a mixture of the javascript, the font and the css although I am not 100% sure.

      • Cheers for that Keir. This will raise the issues of the differences in font heights and such like.

        We’ll have to get clever with our fallbacks so if you do have javascript, the height is x, and if you don’t, then you’ll get a ‘normal’ font so the height is y.

        All progressive loveliness 🙂

    • It’s even worse in Opera 10b on Windows – only the first letter of some words is styled with the Typekit font. I’ve seen this before on others’ demo pages too.

      • Yes, Keir, that’s exactly right. There are three places where inconsistencies can become apparent – in the browsers’ implementation, the internal metrics of the font files, and in how Typekit processes and serves them.

        To address this, our current technology preview is aimed at developing and documenting how the browsers render fonts, working with type designers to optimize existing fonts for the web, and iterate how we serve fonts quickly to address issues we see in the wild.

      • Keir Whitaker on July 31, 2009 at 6:22 pm said:

        Jeffrey – Thanks for stopping by and clarifying the current situation in regard to rendering issues. I for one am really looking forward to seeing how Typekit develops, especially from the technological angle.

Leave a Reply

You must be logged in to post a comment.

man working on his laptop

Are you ready to start learning?

Learning with Treehouse for only 30 minutes a day can teach you the skills needed to land the job that you've been dreaming about.

Start a Free Trial
woman working on her laptop