What Are Variable Fonts?

A variable font is a single font file that contains a continuous design space instead of a set of fixed cuts. Where a static family ships Regular, Medium and Bold as separate files, a variable font stores the design’s extremes and can render any point between them — weight 400, 457, or 610 — from the same file.

The named weights survive as landmarks: 400 still means regular, 700 still means bold, and both render exactly as they would from static files. What changes is that the space between the landmarks opens up — the stops stop being the only options. This article is part of our typography guide.

How is a variable font different from static weights?

A static family is a set of discrete drawings: each weight was exported as its own file, and anything between two weights doesn’t exist. Ask a browser for weight 500 when only 400 and 700 are installed and it either snaps to a neighbor or synthesizes a fake — smearing outlines thicker to simulate bold, with results type designers wince at.

A variable font moves the interpolation into the file. This isn’t a new idea so much as a relocated one: type designers have long drawn a family’s extremes and interpolated the middle weights between them — that’s how large families were produced. A variable font ships the extremes (the masters) and lets the rendering engine interpolate live, so weight 457 is not a fake but a legitimate point in the designed space.

What axes can a variable font have?

Weight is the axis you’ll meet everywhere, but the format is general. A convention of registered axes names the common ones with four-letter tags: wght (weight), wdth (width), slnt (slant), and opsz (optical size — the design adapting to the size it’s set at). Fonts can also define custom axes: grades, softness, whatever the designer parameterized. web.dev’s introduction to variable fonts walks the axes in detail.

Most variable fonts in practice expose one or two axes — weight alone is common — and that’s not a shortcoming. One well-drawn axis covers the large majority of what interfaces need.

Do variable fonts load faster?

Sometimes, and it’s worth being precise about when. A variable file is bigger than any one of its static weights — it carries the whole design space. The honest comparison: a Latin-subset static text weight commonly lands around 15–40 KB in WOFF2, while the variable equivalent often weighs two to four times a single cut. So:

• One weight in use → the static file wins on bytes.
• Two weights → roughly a wash, depending on the family.
• Three or more weights → the variable file usually wins on bytes, and always wins on requests: one file replaces the set.

A team using 400, 500, 600 and 700 of the same family is the textbook case — four requests collapse into one, total bytes typically drop, and every intermediate value comes along free. Exact numbers vary with glyph coverage and subsetting, so measure your own files rather than quoting anyone’s table, including this one.

See a full weight hierarchy in one family — per-style weights from caption to display, previewed at a real scale’s sizes. With static files this hierarchy is four requests; a variable font delivers the same range in one.

How do you use a variable font in CSS?

Declare the range the file covers, then use ordinary properties:

@font-face {
  font-family: "Inter Variable";
  src: url("/fonts/inter-var.woff2") format("woff2");
  font-weight: 100 900;   /* the range, not a single value */
}

h1 { font-weight: 650; }
p  { font-weight: 440; }

font-weight: 457 simply works when the font is variable — no special syntax. The registered axes map onto regular CSS: weight to font-weight, width to font-stretch, slant to font-style, optical size to font-optical-sizing. The low-level escape hatch, font-variation-settings: "XXXX" value, exists for custom axes; prefer the high-level properties wherever they apply, since they compose better with the rest of the cascade.

Why does weight precision matter in a real hierarchy?

Because 400 and 600 don’t always sit right, and with static fonts your only move was to live with it. Two situations come up constantly. Light text on a dark background tends to read thinner than the same weight on white — a body set at 400 can drift toward frail, and 440 quietly corrects it. And a display style at 700 can feel heavier than intended at large sizes, where 640 keeps the presence without the shout. One plausible tuning:

The caption going heavier than the body is deliberate — small sizes thin out optically, and a touch of added weight compensates. Variable fonts also allow animated or responsive weight; it’s a genuine capability, and rarely a load-bearing one.

Which fonts are variable — and how does this fit a token workflow?

Many of the major UI faces ship variable versions — Inter, Roboto Flex, Source Sans 3 and Fraunces are examples — but most font families still don’t, so variable support is a property to check per family, not an assumption. Every current browser engine handles them.

In a token workflow the division of labor is clean: the type system defines per-style weights, and the file format determines which values are renderable. Scale Composer’s per-style weight controls set that hierarchy, and the exported tokens — DTCG, CSS, Tailwind, Figma Variables — carry whatever values you land on: named stops if your family is static, any value at all if it’s variable. The tool’s role is the system, not the file; the font you license decides how finely you can tune it.

Tune the weights instead of accepting the stops

The practical way to understand variable weight is to move it and watch the hierarchy re-balance. Adjust each style’s weight live — nudge the body from 400 toward 440, pull the display back from 700 to 650, and judge the result in running specimen text rather than in a weight slider’s numbers. When a value between the stops reads better, that’s the capability the format exists for — and the exported tokens will carry it.