How do you build a type scale you can actually maintain?

Why does my type scale fall apart after a few months?

Because it had too many steps and no rule for adding one. A scale with fourteen sizes is not a system, it is a menu, and the moment someone needs a heading that sits between two options they invent a fifteenth. Six or seven steps with names survive. Fourteen never do.

I have inherited plenty of sites where the type scale was clearly designed with care and then quietly abandoned. The tell is a stylesheet with three sizes that differ by two pixels and a set of one off overrides on the pricing page.

So this is about building the smaller, meaner version that holds up, and about the naming and tooling decisions that decide whether it holds up at all.

How many steps do you actually need?

Six for most business sites, seven if you have genuinely long form content. One display size, two heading sizes, one body size, one small size for captions and labels, and one tiny size for legal text. Anything beyond that needs to justify itself.

The reason fewer is better is not aesthetic purity. It is that every extra step is a decision someone has to make correctly, forever. Fewer steps means fewer chances for a page to drift, and it means a new person can learn the whole system in a minute.

The constraint also improves the design. When you cannot reach for a slightly different size, you reach for weight, colour, spacing or measure instead, and those usually communicate hierarchy better than a two pixel difference ever did.

Should you use a mathematical ratio?

Use a ratio to generate the first draft and then adjust by eye. A ratio gives you defensible starting values and stops arbitrary choices. It does not know that your headline needs to fit on two lines on a phone.

The common ratios all work. Something gentle keeps headings close to body text, which suits dense, information heavy pages. Something dramatic creates strong contrast, which suits marketing pages with less text. Pick based on how much you are asking a reader to read, not on which ratio sounds most sophisticated.

Where ratios genuinely fail is at the small end. Mathematically correct small sizes are often unreadable, and the fix is to simply overrule the maths. A scale is a tool, not an authority.

What should the steps be named?

Name by role, not by size. Display, heading, subheading, body, small, caption. The moment you name something large or extra large, you have created a naming problem for the next size you add.

Role names also survive redesigns. If you decide next year that headings should be smaller, you change the value behind the name and every page follows. If your name was the size, you now have a token called large that renders at a medium size, and nobody trusts the system again.

This is the single cheapest decision in the whole exercise and the one most often got wrong. It costs nothing at the start and it is expensive to fix later, because the names are already referenced everywhere. The same naming logic applies to every other token you own, which is the wider argument in how to stop a design system from drifting.

How do you store the scale in Webflow?

Store it as variables rather than as values typed into classes. Webflow's own variable tooling exposes variable types for Color, Size, Number, Percentage and FontFamily, so a type scale maps cleanly onto Size variables and a font family variable.

The unit options matter here. Webflow's variable interface accepts px, em and rem, along with ch and a full set of viewport units including vh, vw, dvh, dvw, lvh, lvw, svh, svw, vmax and vmin. That list is worth reading before you commit, because it decides whether your scale can respond to the viewport at all.

My default is rem for type sizes and ch for measure. Rem keeps the whole scale relative to one root value, so you can adjust the entire site's typography by changing a single number. Ch sets line length in characters, which is what readability actually depends on.

Can the scale change at different breakpoints?

Yes, and this is where a variable based scale earns its keep. Webflow's variable system supports named modes within a collection, and a mode can be bound to a breakpoint from its set of breakpoint identifiers, which include the main desktop breakpoint down through medium, small and tiny.

That lets you define one set of type values for desktop and a different set for small screens, without duplicating a single class. The names stay identical and only the values behind them change, which is exactly the property that makes a system maintainable.

The discipline is to change as few values as possible per breakpoint. If every step needs a different value on mobile, your desktop scale is probably too dramatic. One or two adjustments at the display end is usually enough.

What about line height and measure?

They are part of the scale, not afterthoughts. A size without a matching line height is half a decision, and it is the half that determines whether anyone finishes reading.

The pattern I use is simple. Large sizes get tighter line height because the letters are already far apart. Body text gets generous line height because it has to survive being read for minutes. Small text gets slightly more again, because it is usually being read in worse conditions.

Measure is the one people forget entirely. A paragraph that runs the full width of a desktop screen is hard to read regardless of how well chosen the font size is. Constraining line length does more for readability than almost any other typographic choice, which is part of why long form layouts need their own treatment, something I have written about in designing a long article layout people actually finish.

When is it correct to break the scale?

When a single page has a job the system was not designed for, and you are willing to write down the exception. A one off size on a landing page is fine. A one off size nobody documented is the beginning of the decay.

The test I apply is whether the exception will recur. If it will, it belongs in the scale. If it genuinely will not, it can live as a local override with a comment explaining why. What is never acceptable is an override that exists because someone could not find the right token.

Hero sections are the usual pressure point, because they carry more weight than any other block on the site. That is often a structural problem rather than a typographic one, and it is worth checking what the section below is doing before you scale up the headline, which I have covered in what goes in the section right after the hero.

How do you keep it honest over time?

Audit it the same way you would audit anything else: look for values that are not coming from the system. If you find hard coded sizes, either the scale is missing a step people genuinely need, or nobody knows the scale exists.

Both causes have the same fix, which is to write the scale down somewhere a person can read in under a minute. Six names, six values, a sentence about when to use each. Not a design system document. A single short page.

Across more than 70 projects for more than 25 clients over more than six years, the systems that survived were always the ones a new contributor could learn without asking anyone. Sophistication does not survive handover. Simplicity does.

What should you do next?

Open your site and list every distinct font size actually in use. If the list is longer than eight, you have your afternoon's work: decide which six or seven you are keeping, map everything else onto them, and delete the rest.

Then move those values into variables with role based names, so the next change is one edit rather than forty. Do that and the scale stops being a document you wrote once and becomes something the site actually obeys. It is also worth sanity checking how the result reads when structure carries more weight than styling, which I have looked at in what a page needs to survive being read aloud.

If you want a second opinion on a type system before you roll it across a site, reach out. It is much easier to argue about six values than to unpick forty.