A type lockup is a typographic design where the words and characters are styled and arranged very specifically. Like the design is literally locked in place. This idea is slightly at-odds with the responsive web that we know and love, where text is fluid and wrappable and whatnot. Yet, the design possibilities of lockups are very appealing. I think we can hang onto what makes them awesome while still holding onto what makes the web awesome.
First, here’s some examples of type lockups
So we’re on the same page here, let’s look at some example designs.





You get the idea, right? The type in these designs can’t just move around or the design will be broken.
You can find examples all over the place.
Some good places to browse are perhaps:
- Pinterest boards like this or this
- Google image searches
- Dribbble searches
As fate would have it, I took a letterpress course this past weekend
And I learned that a “type lockup” comes from “locking up type”, as in actual wooden or metal blocks of type arranged together with other blocks of wood and metal to make a design that you can literally clamp together, ink up, and press to paper.

Seems like transferring the name “lockup” to modern design is fairly new:
Tiffany Wardle deSousa: I’ve noticed in the last few years that designers have taken the nuts and bolts of letterpress printing—type, image, furniture, all locked up in a chase—and applied it to everything from posters to logos (whether it stylistically makes sense or not). A few of us have been referring to the style as “type lock-ups.”
Dr. Shelley Gruendler: I’ve been noticing it but hadn’t ever actually articulated it enough to come up with a name. Your descriptor “type lock-ups” is perfect.
A typical header on the web isn’t a lockup
Like this:

But we design that way a lot. We do it because it works so well on the responsive web. We can design the type and our site such that it looks pretty good no matter what text ends up there, how long it is, where it wraps, etc. It doesn’t have to be quite that simple, but if type is designed to accommodate wrapping and tolerates fairly major differences in rendering, it’s not really a lockup.
Standard header markup:
<h2>
Nothin' fancy here.
</h2>
This is easy and comfortable to work with from a designer/developer perspective. It’s bread and butter HTML and CSS. Type set like that is accessible, SEO friendly, selectable, on-page searchable, copy-and-pastable, and all that good stuff.
Let’s build a web type lockup. First, we’ll use a web font.
As in, a custom font we could use in our web designs via @font-face
. A custom font we load ourselves, or through any web font service (they all use @font-face
in the end).
Download it for local use
Let’s use Google Fonts because it’s fast, free, and easy. Roboto is nice.
Let’s pick just a couple of weights of it for our design. The same rules apply here as they do for web fonts anywhere: don’t go crazy. Ultimately we’ll load these fonts as resources on the site itself so performance is a concern.

Once you’ve added it to a collection (there is an “add to collection” button) you can click the arrow to open up the area to download it locally.

Activate the font locally
However you do that, do that. I use FontExplorer X myself.

The whole point of installing the font locally is so that we can design in software like Adobe Illustrator
So get creative!
Remember that you can do whatever you want here. You’re free from most of the normal confines of web type. Wanna set a word really small between the ascenders of two much larger letters? That would be pretty dangerous if you were trying to pull it off with absolute positioning in a flexible way, but that’s fair game here.
Here’s my cheezy design:

Keep all the text as *text*
Illustrator is capable of turning text into vector outlines. Don’t do that. Leave the text as editable text.
Save as SVG
SVG is the magic ingredient here.
SVG is what allows the text to remain text. SVG has a literal <text>
element which renders web text in an accessible, selectable (and all that) way. And it remains scalable like anything else in an SVG.
Again, keep the text in SVG, don’t convert it to outlines.

If you open this in a web browser, it will appear as if it works…

But remember to *deactivate* your local fonts for testing
Ooops.

When we use this on the web, we’ll need to load the fonts up and correct the font-family
I’m going to use the typical Google Fonts import:
@import url(https://fonts.googleapis.com/css?family=Roboto:900,100);
Which expects this:
font-family: 'Roboto', sans-serif;
But if we look at the SVG we output from Illustrator, we’re getting:
<text
...
font-family="'Roboto-Black'"
...
>
Meet
</text>
To fix this up, I had to do Find & Replace of
“‘Roboto-Black'” → “Roboto” font-weight=”900″
“‘Roboto-Thin'” → “Roboto” font-weight=”100″
Which ended up with correctly working text elements, like:
<text transform="matrix(0.91387 0.40601 -0.40601 0.91387 56.51732 198.18147)" opacity="0.8" fill="#930093" font-family="Roboto" font-weight="900" font-size="123px">A</text>
Tada!
A darn fine text lockup:

See the Pen Example of a Text Lockup by Chris Coyier (@chriscoyier) on CodePen.
We’ve gone down this road before.
In a post last year, we loaded up fonts from Typekit and did a similar thing, making somewhat of a banner ad type demo:
See the Pen SVG with
This doesn’t rule out RWD stuff
Just because a lockup is scaleable doesn’t mean that elements inside it can’t shift around if that made sense at certain points. Joe Harrison’s responsive logos (a sort of typographic lockup) are an example of how useful hide/show could be:

Moving, resizing, restyling of any kind is fair game. It would be done in CSS either embedded within the SVG document itself (if you were using the SVG as an <object>
) or with all the rest of your CSS that styles the page (if you’re using inline SVG).
@media (max-width: 800px) {
text.letter-1 {
/* do whatever */
}
}
Accessibility
I throw around that this is “accessible” a lot, but of course I’m no expert there. Accessibility means a lot of things.
The fact that I can search for “kids” on a page with this can the browser will find it is certainly a form of accessibility. But I can’t search for “alphabet” because each of the letters are a different <text>
element rather than <tspan>
s. I might be able to fix that by hand, but it would likely be pretty tough. Illustrator doesn’t really help with that.
And source order I would imagine is pretty important too, as it’s the order in which things are read (if we’re talking screen reader accessibility) and indexed. I should have taken more care to get that right. Fortunately Illustrator can help with that, as the layer order is the output order.

Here’s some more examples
Recreation of a magazine article header I saw:
See the Pen Magazine Layout Attempt #2 by Chris Coyier (@chriscoyier) on CodePen.
Brenna O’Briens example from a talk (note the <tspan>
s)
See the Pen SVG Typographic Lock-up by Brenna O’Brien (@brenna) on CodePen.
Yet another possibility
This is all very related to “scaled proportional content” which we just covered here on CSS-Tricks. Going down that road is a possibility as well (fixed height/widths, scale()’d).
Another possibility is setting type with viewport units, which scale with the browser window and thus could probably be used to lay out type in a way that scales without breaking. Maybe. There isn’t any software to help you with this and it’ll likely be full of a lot of magic numbers, but have the advantage that you get to use semantic HTML elements.
Ana Tudor has tackled this in the form of porportional slides, with a helpful Sass mixin:
See the Pen Proportional box covering viewport (mixinized) by Ana Tudor (@thebabydino) on CodePen.
Very very interesting. If you are using SVG text on a website, what sort of accessibility hits can we expect? I’m assuming that if it is text a screen reader can still read it?
I happened to research that a bit the other day, and had some advice from Amelia Bellamy-Royds: if the SVG contains only text and you’re using it inline, might be best to slap a
role="presentation"
on the<svg>
-element, which preserves the actual text content as accessible text but removes all other semantics. I tested that in VoiceOver & NVDA, both handled it fine.Otherwise (if the SVG is a mix of text and graphics), might be best to go with
role="img"
, and augment that with anaria-labelledby="foo bar"
(still on the<svg>
), wherefoo bar
could point to theid
:s of<title>
and<desc>
elements inside the SVG, respectively. The accessible text would then be duplicated inside those.I recently used this technique for a client (http://www.thebodydeli.com/) on the home page where it says “Welcome to the Body Deli”. Once I got the SVG into Chrome, I had to increase the font-size a touch for the text to fill the space correctly. It is using a copy of Gill Sans webfont that is on the server. However, in Firefox, the text is now too short and it doesn’t extend all the way to the right as expected. So it seems there are still cross-browser issues preventing true typographical lockup.
Any thoughts on how to deal with this?
This has been my issue with responsive web designs. They give you a grid, but as someone who knows and follows proper print graphic fundamentals I always think what the fuck is the point of a grid or anything when you don’t know what it will look like on all those different screen widths. It will never be perfect on every screen. Makes me so frustrated in regard to creating web designs.
A while back I made a quick Pen to handle full width justified text using a very similar method. Feel free to steal the JS that does the auto calculations.
Hey, I really like that!
Though without JS enabled, no text is visible at all – which, since accessibility is already a discussion point here, is rather bad; at least if one wanted to use that for actual content (say, as an effect for headlines or pull-quotes.)
But I guess that could be fixed by adding a proper viewbox attribute to the svg elements in the HTML source to begin with? (That wouldn’t scale the text of course, but could simply display it as separate lines of text, with font-size the same for each line.)
@ChrisB, that’s definitely true. I had put this one together as a light weight proof of concept. It would need a few additions to be production ready.
Nicely done, Chris! I love Emil’s comment to make it accessible, too. Amazes me how much we’ve advanced, especially in comparison to my CSS type experiment from 2007. Great stuff.
Thanks Jon! In my eagerness, I forgot to mention that SVG text is probably accessible by default for most, the added ARIA-attributes are more of a “belt and suspenders”-type thing to try and make sure. If anyone has further research on how browsers handle it I’d love to learn more.
If you want to get top quality logo design at an affordable price, then choose UK Logos.