---
title: "Two rules can center a button. They cannot choose your UI font"
locale: "en"
url: "https://irz.fr/en/articles/ui-font-four-gates-en"
markdown_url: "https://irz.fr/en/articles/ui-font-four-gates-en.md"
category: "craft"
tags: ["typography", "interface", "Inter", "design systems", "CSS"]
published_at: "2026-08-26T11:12:00.000Z"
author: "Camille Morel"
translation: "https://irz.fr/fr/articles/police-ui-quatre-gates-fr.md"
---

# Two rules can center a button. They cannot choose your UI font

Tall x-height and cap-centered vertical metrics remove a lot of button nudging. A UI font still has to pass the tests of numerals, language coverage and licensing before it ships.

A button can have exactly `12px` of padding above and below its label and still look too low. The developer removes one pixel, the designer puts two back somewhere else, and the same component starts leaning again as soon as the text size changes.

Yep! Type offers a much less mystical explanation: inspect **the font's vertical box** and **the height of its lowercase letters** before repairing the component.[1](https://yeptype.com/article/inter-alternatives)

The article recommends two criteria for interface type. First, vertical metrics with roughly equal space above the cap height and below the baseline. Second, a large x-height, around 70–75% of cap height, with 75% as the author's preferred UI target.[1](https://yeptype.com/article/inter-alternatives)

Those rules are useful because they turn a vague visual annoyance into something measurable. They also help explain why Inter fits so easily into design systems.

They are not enough to choose a font that has to survive a real product.

## Gate 1: the box

A font does not only provide the outline of `H`, `x` or `8`. It also contains metrics that tell layout engines how much vertical room belongs around those shapes.

When the capital sits much closer to the top of its box than the baseline sits to the bottom, a label can look off-centre inside a button even when CSS padding is mathematically equal. Yep! Type therefore recommends cap-centred metrics: the air above a capital should resemble the space left below the baseline.[1](https://yeptype.com/article/inter-alternatives)

Its proposed test is almost comically simple. In Figma, set the text to 1000px, reduce line-height until the box approaches the glyphs, and watch whether the top reaches the capitals at the same moment the bottom meets the baseline.[1](https://yeptype.com/article/inter-alternatives) No quantum-typography plugin required, to the inevitable disappointment of somebody.

This is not an accessibility standard and it does not make one font universally correct. It mostly removes a class of local fixes. When a design system contains fifty buttons, badges, tabs and fields, removing that friction at the font level is more valuable than carrying `padding-top: 1px` through fifty components.

> **Gate one: the type box**
> IRZ diagram showing H and x inside a vertical type box with cap height, x-height and baseline.
> - Hx
> - CAP HEIGHT
> - X-HEIGHT
> - BASELINE
> - Equal padding behaves better when the font is not already off-centre.
> Yep! Type recommends metrics that place the capital centrally inside the useful vertical box. This is an interface workflow heuristic, not a universal typographic law.

## Gate 2: reading

X-height measures the height of a lowercase `x` against a reference inside the font. In the source article, the comparison is against cap height: all ten shortlisted alternatives fall between **70 and 75%**.[1](https://yeptype.com/article/inter-alternatives)

A large x-height gives lowercase letters more visual presence at the same CSS font size. In a 13 or 14px label, words can appear larger and steadier without increasing `font-size`. That is one practical reason many grotesks intended for interface work use generous lowercase forms.

The Yep! Type shortlist can therefore be read for exactly what it measures:

| Font | x-height / cap height measured by Yep! Type |
| --- | ---: |
| Innovator Grotesk | 75% |
| Universal Sans | 75% |
| Plain | 73% |
| SwissNow | 73% |
| Muoto | 72% |
| Aktiv Grotesk | 72% |
| Akkurat | 71% |
| Basier | 71% |
| CoFo Sans | 70% |
| Unifora | 70% |

Yep! Type also describes all ten as having the desired centred vertical metrics.[1](https://yeptype.com/article/inter-alternatives) This table is therefore **not** a general ranking of the best Inter replacements. It says only that these fonts passed the two tests this author chose to measure.

The 75% target deserves the same caution. A very high x-height may help a small Latin label without being ideal for a headline, long-form reading or another writing system. Optical behaviour also changes with weight, width, contrast and size.

Inter acknowledges that directly in its own construction. The family has an optical-size axis running from text to display, and its text-oriented design uses a tall x-height along with details intended to preserve contrast at small sizes.[2](https://rsms.me/inter/) Apple solves a related problem at system level: SF Pro provides variable optical sizes and the operating system can apply size-specific behaviour automatically.[4](https://developer.apple.com/fonts/)

In other words, **the proportion of `x` is a signal, not the whole legibility engine**.

## CSS catches up

Part of the first gate may also become less restrictive as browsers improve.

The CSS property `text-box-trim`, together with `text-box-edge`, lets authors trim the text box against typographic edges instead of accepting only the vertical metrics embedded in the font.[7](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/text-box-trim) For a web component, that is exactly the kind of tool that can reduce pressure to choose a font merely because its default rectangle behaves nicely.

Support is moving quickly. The Yep! Type article still described Firefox as unsupported and quoted roughly 79% global coverage.[1](https://yeptype.com/article/inter-alternatives) On August 26, 2026, Can I Use reports about **84.23%** global usage support and desktop Firefox support from version 154.[8](https://caniuse.com/mdn-css_properties_text-box-trim) MDN still marks `text-box-trim` as limited availability and not Baseline,[7](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/text-box-trim) while Firefox for Android remains behind in the current Can I Use table.[8](https://caniuse.com/mdn-css_properties_text-box-trim)

The practical rule is therefore not “vertical metrics no longer matter.” It is that **the platform is gaining a way to repair the box, while x-height and glyph design remain properties of the font**.

## Gate 3: data

This is where we leave the beautiful row of buttons in the mockup.

Real products display prices, identifiers, times, versions, IP addresses, code, tables and sometimes thousands of aligned numbers. A UI font starts revealing different qualities that never appear in an `Hx` test.

Inter provides **tabular figures**, where digits keep a fixed width so a numeric column does not wobble when `118` becomes `902`.[2](https://rsms.me/inter/) It also offers a slashed zero and stylistic sets for distinguishing similar glyphs.[2](https://rsms.me/inter/) In a dense admin interface, the difference between `0` and `O`, or between `1`, `l` and `I`, may matter more than half a percentage point of x-height.

Weights, italics, numeral styles and OpenType features also need to match the product. Inter spans weights 100–900, includes a true italic and contextual alternates in addition to its optical sizes.[2](https://rsms.me/inter/)

None of this makes Inter automatically superior to every font in the table. We have not independently verified the entire numeral system, OpenType inventory and commercial licensing of all ten alternatives. Doing so would turn an article about selection method into a foundry licensing spreadsheet, a species of document the world already produces with alarming enthusiasm.

It simply explains why a third gate exists.

> The button is only the beginning
> **Four gates before shipping**
> - Does text fall naturally into the centre of interface components?: Box
> - Do lowercase and small sizes remain readable without inflating the whole UI?: Reading
> - Do tabular figures, 0/O, 1/l/I, weights and OpenType features fit the product?: Data
> - Do languages, scripts, licensing and distribution actually cover the target platforms?: Reach
> The first two gates come from the Yep! Type heuristic; the latter two are IRZ's deployment layer.

## Gate 4: reach

A font can centre `Save` perfectly and fail on the first translated screen.

Inter's current site reports **more than 2,000 glyphs and 147 languages**.[2](https://rsms.me/inter/) Its SIL Open Font License 1.1 permits use, study, modification and redistribution under OFL conditions.[3](https://github.com/rsms/inter/blob/master/LICENSE.txt) That combination of coverage and licensing is part of its operational convenience: a team can put it in a product, serve it on the web and adapt it without negotiating a separate licence per designer seat or traffic bracket.

System fonts solve the reach problem differently. Apple presents SF Pro as the system font for its platforms, with nine weights, four widths, variable optical sizes and support for more than 150 languages across its Latin, Greek and Cyrillic sets.[4](https://developer.apple.com/fonts/) Microsoft describes Segoe UI as a family designed for screen use, while Segoe UI Variable uses variable-font technology to improve behaviour at small sizes and provide different outlines at larger ones.[5](https://learn.microsoft.com/en-us/windows/apps/design/signature-experiences/typography)[6](https://learn.microsoft.com/en-us/typography/font-list/segoe-ui)

Those families gain platform integration that an independent webfont cannot have. In exchange, availability and redistribution do not follow the same model as an OFL font that can simply travel with the product.

This is where an “Inter alternative” stops being merely an aesthetic choice. An international application has to test the scripts it genuinely needs, the fallback used when a glyph is missing, the metrics of that fallback, and distribution rights on every target environment.

## The four-line test

The Yep! Type article gives a very good first filter because it can quickly eliminate fonts that would force a team to nudge every interface control by hand.[1](https://yeptype.com/article/inter-alternatives) Its ten alternatives become more useful as a starting set than a “fonts like Inter” gallery assembled only by visual resemblance.

IRZ would add three lines below the `Hx` test:

1. type `001279 88:11 1Il0O` and inspect figures, widths and ambiguous forms;
2. render the languages the product actually supports rather than one English pangram;
3. read the licence and verify how the font will travel through web, apps and design files.

A fourth check, small-size rendering, cuts across the others: test the font where the interface will really use it, on the target screens and rendering engines, rather than at 72px in a specimen page.

A mockup lets you choose shapes. A product makes you choose **a typographic system**.

That may be the simplest reason Inter became so ordinary: it is not merely easy to like inside a button. It removes a respectable number of problems after the button too.

## References

1. [Yep! Type, How to choose a UI font (and 10 Inter alternatives), 2026](https://yeptype.com/article/inter-alternatives)
2. [Rasmus Andersson, Inter](https://rsms.me/inter/)
3. [Inter, SIL Open Font License 1.1](https://github.com/rsms/inter/blob/master/LICENSE.txt)
4. [Apple Developer, Fonts for Apple platforms](https://developer.apple.com/fonts/)
5. [Microsoft, Typography in Windows apps](https://learn.microsoft.com/en-us/windows/apps/design/signature-experiences/typography)
6. [Microsoft Typography, Segoe UI font family](https://learn.microsoft.com/en-us/typography/font-list/segoe-ui)
7. [MDN, text-box-trim](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/text-box-trim)
8. [Can I Use, CSS text-box-trim](https://caniuse.com/mdn-css_properties_text-box-trim)