Variable fonts shipped in 2016, four-weight habit survived

The format

A variable font is a single OpenType file with one or more axes baked into it. Twist the weight axis and you get anything from Thin to Black; twist the width axis and the letterforms stretch or compress — not by scaling, but by interpolating between masters the type designer drew and embedded. OpenType 1.8, published by Microsoft, Adobe and Google in September 2016, formalized the variable font specification. Browser support arrived fast: Chrome 62 shipped in October 2017, Firefox 62 in September 2018, and Safari had partial support from 11.0 in late 2017. As of 2025, every current engine reads variable fonts without a flag.

The file is usually larger than a single static weight but smaller than four. A project shipping Regular, Medium, SemiBold, and Bold as separate .woff2 files carries four HTTP requests and four decode operations. One variable file with a weight axis covers the same range — and every stop between — in a single request. The compression story is good: .woff2 wraps the variable format cleanly, and Brotli compression, available in all current servers, cuts transfer size further.

1. September 2016OpenType 1.8 published; variable font spec formalized
2. October 2017Chrome 62 ships variable font support
3. September 2018Firefox 62 ships variable font support
4. ~2020Google Fonts begins serving variable files by default for supported faces
5. 2022Figma adds meaningful axis control to its type panel

Why the static habit persisted

The tooling lagged the spec. Figma added variable font support to its type panel gradually, with meaningful axis control not landing until 2022. Before that, a designer working in static weights handed off a spec that referenced static weights, a developer matched it, and the build shipped four files. The loop reinforced itself.

Google Fonts began serving variable fonts by default for faces that support them around 2020, but the API's old syntax — ?family=Inter:400,700 — would still return statics if you called it that way. The updated syntax uses a weight range: ?family=Inter:wght@100..900. Many codebases still carry the old string, copied from a 2018 Stack Overflow answer.

The compression story is good: .woff2 wraps the variable format cleanly, and Brotli compression, available in all current servers, cuts transfer size further.

CSS has had font-variation-settings since the same browser cycle. The property accepts axis tags in four-letter codes defined by the spec — wght for weight, wdth for width, ital for italic, slnt for slant — plus any custom axis a foundry defines. The higher-level properties font-weight, font-style and font-stretch map to the registered axes automatically; font-variation-settings exists for everything else. Setting font-weight: 350 on a variable font works correctly. Setting it on a static font snaps to the nearest available weight. That is the practical difference in a stylesheet.

Rasmus Andersson's Inter, released as a variable font with a weight axis spanning 100 to 900, became the clearest demonstration that the format worked at production scale. Kris Sowersby at Klim Type Foundry took a different position: Söhne ships as separate files per style, a choice reflecting the foundry's view that each master should be its own object. Both positions are coherent; they just produce different delivery strategies and different licences. The format does not mandate the workflow.

The honest case for variable fonts is not that they are new — they are nearly a decade old — but that the friction point was never browser support. It was design-tool representation, API syntax and the weight of existing build patterns. Those gaps have closed. A project starting today that reaches for four static .woff2 files is not being careful; it is being inertial.

The axis is there. The file is smaller than the alternative. The CSS already knows what to do with it.