Variable fonts in digital branding
Why variable fonts emerged and what they technically change
Before the introduction of the variable fonts format (OpenType specification 1.8, 2016 year), each style — Regular, Medium, Bold, Bold Italic — was stored in a separate file. The variable format encodes all styles as points on axes within a single file. Five standard axes are registered: weight (wght), width (wdth), slant (slnt), italic (ital), and optical size (opsz), and brands can add their own.
The effect on file size is noticeable. Monotype provides a calculation: 48 static variants of one font (8 weights × 3 widths × roman/italic) weigh noticeably more in total than one variable file with the same set of styles — the savings reach 88%. In practice, this translates into loading speed: one WOFF2 with smart subsetting for Latin script (around 75 KB) versus five static files (roughly 325 KB) improves LCP on a slow 3G with 2,4 seconds to 0,8. For a brand, this is not an abstract metric — it's the difference between 'the site opened smoothly' and 'the text flickered with an unreadable fallback'.
When a variable font is justified, and when a static one — it's wiser
The technology is not universal, and implementing it 'just because it's trendy' is a mistake that later costs a lot during the support stage. The working rule is simple: if three or more weights of the same font are used in the system, or if glyph animation is planned (a logo that reacts to context, headers, 'breathing' on scroll), then the variable file wins in both weight and flexibility. If only one or two variations are needed in the project without animation, a static file is often lighter: the overhead of the variable format for storing axes is not offset.
| Criterion | Static font | Variable font |
|---|---|---|
| Number of variations in the project | 1–2, without intermediates | 3+ or a smooth transition is required |
| Typography animation | Not natively supported | Key strong point |
| File weights | Smaller with a small number of styles | Smaller with a large number of styles |
| Designer control | Limited to ready-made styles | Requires discipline and a scale of values |
| Support for older browsers/software | Universal | A check is needed, especially in print pipelines |
Optical size: an underrated axis that works on readability
The opsz axis is what is most often skipped in design systems, although it directly affects brand receptivity. The idea is simple: a letter for microtext should have thicker strokes and more open counters than the same letter in a large headline — otherwise, at small point sizes it 'sticks together'. Boehringer Forward, the pharmaceutical brand font, solves this task through three optical sizes — Display, Text and Micro — and 36 multilingual styles. The range of application is extremely wide: from microtext on medicine packaging, where a mistake in dosage writing is unacceptable, to macrotext on billboards. Without separate optical adjustment, such a range of scales would have to be covered by a compromising typeface that works poorly in both cases.
How not to lose brand recognizability with thousands of available options
A variable font technically permits an infinite number of intermediate values — and that is a trap. If every designer and developer is free to choose any number on the scale, brand identity spreads into dozens of barely distinguishable versions of the same mark. The solution is not to expand the palette of styles, but to fix a finite set of 'master values' and prohibit everything that lies between them.
A telling example is the variable logo of Evri (formerly Hermes): the shape of the letters changes depending on the context through a user axis [EXPR] with 20 alternative glyphs for each letter, generating 194 481 possible combinations, yet recognizability is preserved thanks to a unified system of metrics. Flexibility exists, but it is channeled into rigid constraints. A similar principle applies to Schibsted Grotesk: the font covers more than 220 languages through 496 glyphs, built on four weight masters (from Regular 400 to Extra Bold 800) with corresponding italics, which in total yields 12 styles. None of these brands gave the team freedom to 'use any number from 100 to 900' — freedom without constraining the axis is the source of visual noise.
The hidden gap between the engineering implementation and the design system
The main problem with implementation is not technical but organizational: Figma and CSS interpret variant styles differently. Figma has historically been accustomed to working with named, fixed text styles — 'Regular', 'Medium', 'Bold'. CSS and the font format itself operate on continuous axes — { wght: 450, opsz: 16 }. There is still no standard way to represent a pair of axis values as a single token in a design system, so teams invent their own conventions, and they diverge: the token says 'Medium = 500', but in reality the designer in Figma moved the slider to 470, because 'that looks better on this mockup'.
There is also a historical legacy code problem. In the John Lewis case, transitioning to variable fonts turned out to be more difficult than expected precisely because the legacy codebase contained workarounds — for example, font-weight: 500 was used as a pseudo-'normal' due to previous design errors. It was necessary to rewrite CSS (de-bolding) and coordinate the work of several teams simultaneously, although the actual replacement of the font file would have taken only a day.
A separate risk area is subsetting. A variant file with all language sets weighs a lot, so it is trimmed to the required alphabets. An error in subset does not produce an obvious build error — it manifests as a 'silent' bug: strange rendering, missing glyphs, but only in specific locales that often do not make it into the test run.
What needs to be rebuilt in team processes
Transitioning to variable fonts requires changes not in the tool, but in agreements between people who use this tool.
- Fix the final scale of axis values (for example, only 400/500/650/800 for wght) and explicitly prohibit arbitrary intermediate numbers in tokens.
- Align a unified naming dictionary between Figma styles and CSS variables — each named typeface should unambiguously resolve into a specific pair of axis values.
- Introduce a separate check for subsetting before release: verify rendering in all used locales, not just the main one.
- Specify the rule for working with optical size — at which breakpoints and font sizes opsz automatically switches, so this is not solved by eye every time anew.
- Conduct a legacy-CSS audit before migration: identify and remove bypass values of font-weight inherited from previous limitations of static files, before enabling the variable font, not after.
Variable fonts give the brand a resource that did not exist with static files: one tool instead of a dozen, animation, readability at any scale. But this resource only works where flexibility is constrained by discipline — a final set of values, a unified dictionary between design and code, and proven subsetting. Without this, variability turns not into an advantage, but into a way to subtly blur the identity that the brand has built over the years.
The effect on file size is noticeable. Monotype provides a calculation: 48 static variants of one font (8 weights × 3 widths × roman/italic) weigh noticeably more in total than one variable file with the same set of styles — the savings reach 88%. In practice, this translates into loading speed: one WOFF2 with smart subsetting for Latin script (around 75 KB) versus five static files (roughly 325 KB) improves LCP on a slow 3G with 2,4 seconds to 0,8. For a brand, this is not an abstract metric — it's the difference between 'the site opened smoothly' and 'the text flickered with an unreadable fallback'.
When a variable font is justified, and when a static one — it's wiser
The technology is not universal, and implementing it 'just because it's trendy' is a mistake that later costs a lot during the support stage. The working rule is simple: if three or more weights of the same font are used in the system, or if glyph animation is planned (a logo that reacts to context, headers, 'breathing' on scroll), then the variable file wins in both weight and flexibility. If only one or two variations are needed in the project without animation, a static file is often lighter: the overhead of the variable format for storing axes is not offset.
| Criterion | Static font | Variable font |
|---|---|---|
| Number of variations in the project | 1–2, without intermediates | 3+ or a smooth transition is required |
| Typography animation | Not natively supported | Key strong point |
| File weights | Smaller with a small number of styles | Smaller with a large number of styles |
| Designer control | Limited to ready-made styles | Requires discipline and a scale of values |
| Support for older browsers/software | Universal | A check is needed, especially in print pipelines |
Optical size: an underrated axis that works on readability
The opsz axis is what is most often skipped in design systems, although it directly affects brand receptivity. The idea is simple: a letter for microtext should have thicker strokes and more open counters than the same letter in a large headline — otherwise, at small point sizes it 'sticks together'. Boehringer Forward, the pharmaceutical brand font, solves this task through three optical sizes — Display, Text and Micro — and 36 multilingual styles. The range of application is extremely wide: from microtext on medicine packaging, where a mistake in dosage writing is unacceptable, to macrotext on billboards. Without separate optical adjustment, such a range of scales would have to be covered by a compromising typeface that works poorly in both cases.
How not to lose brand recognizability with thousands of available options
A variable font technically permits an infinite number of intermediate values — and that is a trap. If every designer and developer is free to choose any number on the scale, brand identity spreads into dozens of barely distinguishable versions of the same mark. The solution is not to expand the palette of styles, but to fix a finite set of 'master values' and prohibit everything that lies between them.
A telling example is the variable logo of Evri (formerly Hermes): the shape of the letters changes depending on the context through a user axis [EXPR] with 20 alternative glyphs for each letter, generating 194 481 possible combinations, yet recognizability is preserved thanks to a unified system of metrics. Flexibility exists, but it is channeled into rigid constraints. A similar principle applies to Schibsted Grotesk: the font covers more than 220 languages through 496 glyphs, built on four weight masters (from Regular 400 to Extra Bold 800) with corresponding italics, which in total yields 12 styles. None of these brands gave the team freedom to 'use any number from 100 to 900' — freedom without constraining the axis is the source of visual noise.
The hidden gap between the engineering implementation and the design system
The main problem with implementation is not technical but organizational: Figma and CSS interpret variant styles differently. Figma has historically been accustomed to working with named, fixed text styles — 'Regular', 'Medium', 'Bold'. CSS and the font format itself operate on continuous axes — { wght: 450, opsz: 16 }. There is still no standard way to represent a pair of axis values as a single token in a design system, so teams invent their own conventions, and they diverge: the token says 'Medium = 500', but in reality the designer in Figma moved the slider to 470, because 'that looks better on this mockup'.
There is also a historical legacy code problem. In the John Lewis case, transitioning to variable fonts turned out to be more difficult than expected precisely because the legacy codebase contained workarounds — for example, font-weight: 500 was used as a pseudo-'normal' due to previous design errors. It was necessary to rewrite CSS (de-bolding) and coordinate the work of several teams simultaneously, although the actual replacement of the font file would have taken only a day.
A separate risk area is subsetting. A variant file with all language sets weighs a lot, so it is trimmed to the required alphabets. An error in subset does not produce an obvious build error — it manifests as a 'silent' bug: strange rendering, missing glyphs, but only in specific locales that often do not make it into the test run.
What needs to be rebuilt in team processes
Transitioning to variable fonts requires changes not in the tool, but in agreements between people who use this tool.
- Fix the final scale of axis values (for example, only 400/500/650/800 for wght) and explicitly prohibit arbitrary intermediate numbers in tokens.
- Align a unified naming dictionary between Figma styles and CSS variables — each named typeface should unambiguously resolve into a specific pair of axis values.
- Introduce a separate check for subsetting before release: verify rendering in all used locales, not just the main one.
- Specify the rule for working with optical size — at which breakpoints and font sizes opsz automatically switches, so this is not solved by eye every time anew.
- Conduct a legacy-CSS audit before migration: identify and remove bypass values of font-weight inherited from previous limitations of static files, before enabling the variable font, not after.
Variable fonts give the brand a resource that did not exist with static files: one tool instead of a dozen, animation, readability at any scale. But this resource only works where flexibility is constrained by discipline — a final set of values, a unified dictionary between design and code, and proven subsetting. Without this, variability turns not into an advantage, but into a way to subtly blur the identity that the brand has built over the years.
Recent articles
MegaFon, BMW, VTB and more 240+ companies. See how it looks in the showcase reel:
Our branding agency is approached to order:
Branding agency services
