I spent the first two years of my career as a graphic designer before I learned to code. When I finally crossed over to development, I brought one thing with me that most developers don't have: an obsession with type.

What I discovered was that most developer-built UIs have the same quiet problem. The layout is solid. The logic is clean. But you land on the page and something feels off — slightly uncomfortable, slightly hard to read. You can't name it. You close the tab. The product fails not because the code was bad, but because nobody thought seriously about how the words were set.

That's a typography problem. And it's fixable with about three hours of focused learning.

Why Developers Skip This

The honest answer: typography looks like a soft skill. It lives in the design file, not the codebase. It doesn't break tests. There's no linter that catches bad line-height. So it falls through the gap between designer and developer — and when there's no designer on the team, it falls through entirely.

But here's the thing — you are already making typographic decisions. Every time you write font-size: 16px or line-height: 1.5, you're making one. The question is whether you're making them well or by accident.

The Four Things That Actually Matter

1. Line Height (Leading)

This is the single biggest lever you have. Bad line-height is why so many apps feel cramped or impossible to read. The rule is simple: body text needs room to breathe. For most body copy, aim for a line-height between 1.5 and 1.75 — never lower than 1.4 for anything longer than a headline.

// Bad — line-height: 1.2
Building things at the intersection of design and code means you have to hold two modes of thinking simultaneously. You have to be precise and systematic while also being intuitive and visual.
// Good — line-height: 1.75
Building things at the intersection of design and code means you have to hold two modes of thinking simultaneously. You have to be precise and systematic while also being intuitive and visual.

Same words. Same font. Same font-size. Completely different reading experience. This is why line-height matters more than almost any other typographic choice.

2. Measure (Line Length)

The ideal line length for body text is 60–80 characters. Too short and your reader's eye bounces constantly. Too long and they lose their place returning to the next line. This is why full-width text blocks feel so uncomfortable — your eye has to travel too far.

In CSS, the simplest way to control this is with max-width: 65ch on your text container. The ch unit is the width of the "0" character, making it a reliable proxy for character count.

/* Readable body text */
.article-body {
  max-width: 65ch;
  line-height: 1.75;
  font-size: 1rem;
}

3. Typographic Scale

Random font sizes are the hallmark of a developer-built UI. When you eyeball heading sizes, you end up with a page where H1 is 32px, H2 is 26px, H3 is 20px, and body is 16px — technically descending, but without any visual rhythm or harmonic relationship.

A proper typographic scale uses a fixed ratio between each step. The most commonly used scale ratios are the Major Third (1.25) for compact UIs, or the Perfect Fourth (1.333) for more expressive layouts. Starting from a base of 16px:

/* Major Third scale — base 16px */
--text-xs:   10px;   /* 16 / 1.25 / 1.25 */
--text-sm:   13px;   /* 16 / 1.25 */
--text-base: 16px;
--text-md:   20px;   /* 16 × 1.25 */
--text-lg:   25px;   /* 16 × 1.25² */
--text-xl:   31px;   /* 16 × 1.25³ */
--text-2xl:  39px;   /* 16 × 1.25⁴ */
--text-3xl:  49px;   /* 16 × 1.25⁵ */

Use this scale consistently across a project and your hierarchy will feel natural and intentional — even if nobody can articulate why.

4. Contrast Hierarchy

Not everything should be the same colour. Developers often set all text to white or near-black and leave it there. But a real typographic system uses three levels of contrast: primary text for core content, secondary text for supporting information, and muted text for metadata and labels.

/* Three-tier text hierarchy */
--text-primary:   #ffffff;    /* Headlines, important body */
--text-secondary: #a0aab4;    /* Supporting copy, descriptions */
--text-muted:     #4a5568;    /* Labels, dates, metadata */

Scan any well-designed app and you'll see this pattern everywhere. It's not decoration — it's a reading guide that tells your user what to pay attention to first.

The One Font Rule

When in doubt, use one font family. Not two. One. Then use weight (300 vs 700) and size to create variety. Using multiple typefaces requires real typographic knowledge to pull off well — the wrong pairing creates visual noise that undermines everything else you've built.

If you do want to use two families, the most reliable combination is: a geometric sans-serif for UI text and a monospaced font for code, labels, and metadata. This is the combination you see on almost every developer portfolio and design system — and it works because it creates a clear semantic distinction between content types.

You don't need to become a typographer. You need to stop making typographic decisions by accident.

Practical Checklist

Next time you're building a UI from scratch, run through this before shipping:

That's it. No design degree required. Just a little intentionality applied to decisions you were already making.

The web is mostly words. Learning to set them well is one of the highest-leverage skills a developer can add to their toolkit — and almost nobody does.