Type legibility checker
The minimum readable size for your colours — corrected for your font.
872 families from the Google Fonts catalogue, with real metrics. Showing 300 — narrow the filter to see more.
Inter has an x-height 5% above the reference, so 15.5px is enough where the table says 16px.
5% above APCA's 0.52 reference.
Long. Finding the start of the next line gets harder as the measure grows.
The quick brown fox jumps over the lazy dog. Legibility is not a matter of taste; it is a measurement, and it changes with the typeface you set it in.
Metrics are read from a table built into this page, covering 872 families. 48 families are left out because their font files report no x-height, or one too small to be believable. Previews fetch the face from Google Fonts; your colours and sizes stay in the browser.
In short
Every contrast checker will tell you whether a colour pair passes. A few will tell you the minimum font size that pair supports. None of them ask which typeface you are setting it in, and that omission changes the answer.
What minimum readable font size is
The smallest size at which text of a given weight, in a given typeface, at a given contrast, remains readable. It is not a property of the size alone: point size describes the em box, and what a reader perceives is the x-height inside it, which differs by a third or more between families.
What this tool does that others do not
The x-height correction, applied automatically
APCA’s font lookup table is calibrated against a reference x-height, and its numbers are progressively wrong for families that sit away from it. Its own specification describes the fix — divide the reference by your font’s x-height and multiply the minimum size by the result. Doing it automatically, against real metrics, is what is unusual.
The reference is 0.52 em, near Helvetica at 0.523. Of the 872 families measured here, a substantial share sit more than 10% below it.
Metrics from the font files, with the gaps admitted
x-height, cap height and average advance width come from each font’s OS/2 table by way of the Capsize project. Families whose files report no x-height, or one below 0.35 em, are excluded rather than estimated — a missing measurement is reported as missing.
872 families measured, 48 excluded as unmeasurable.
Characters per line from real advance widths
Size is only half of legibility. The usual rule of thumb divides the column width by half the font size, which is wrong by a wide margin for condensed and monospaced faces. This uses the font’s own average advance width, so the count reflects the typeface you actually chose.
How to use it
Pick the typeface first
The answer changes with the family, so choosing a size before a font is doing it in the wrong order.
Enter the colours you are shipping
Contrast and size trade against each other. A pair that only just clears AA demands more size than one that clears it comfortably.
Read both numbers
The WCAG 2 ratio is what conformance is measured against in most of the world; the APCA figure is the better predictor of whether the text can be read. Where they disagree, that disagreement is the finding.
Apply the corrected minimum, not the table one
The table value is only correct for a font near the reference x-height. The corrected number is the one for your font.
Worked examples
Real input, real figures.
A high-contrast old-style serif at body size
You give it
EB Garamond, x-height 0.400 em, against a lookup minimum of 18px.
You get
0.52 ÷ 0.400 = 1.3, so the real minimum is about 23px. Helvetica, at 0.523 em, needs the 18px the table gave — which is why two designs that both "use 18px body" can differ completely in how they read.
Two serifs that look like the same requirement
You give it
Source Serif 4 and Merriweather, same contrast, same weight.
You get
Source Serif 4 needs roughly 20px where Merriweather needs 17px — a 17% difference in the size you have to set for the same readable result.
Against a contrast checker that reports a minimum size
| Aspect | This tool | A typical checker |
|---|---|---|
| Typeface | An input; the answer depends on it | Not asked |
| x-height correction | Applied from the font file | Not applied |
| Metric source | 872 families read from OS/2 tables | None |
| Line length | Counted from real advance widths | Not offered |
| Unmeasurable fonts | 48 excluded and named as excluded | Estimated or ignored |
Guide
What it will not do
- No font upload, and no font export. Measurements derived from a typeface are facts about it; a converted or subsetted font file is a derivative work, and distributing one is the foundries’ business rather than ours.
- It will not guess. A family whose file reports no credible x-height is left out, because a confident number with nothing behind it is worse than an absent one.
The em box is not what you read
Font size describes the em box, an invisible container. What a reader actually perceives is the height of a lowercase x — the x-height. That varies enormously between typefaces. Set 16px in one face and 16px in another and the second can look a full size smaller, because it is: fewer pixels of ink, same nominal measurement.
APCA's font lookup table, which is where minimum sizes come from, is calibrated against a reference x-height of 0.52 em — near Helvetica, which measures 0.523. Its numbers are correct for fonts sitting near that reference, and progressively wrong for fonts that do not. Of the 872 families measured here,166 — about 19% — sit more than 10% below it.
What the correction does
APCA's specification already describes the fix: divide the reference x-height by your font's x-height, and multiply the minimum size by the result. A font with a smaller x-height needs to be set larger to deliver the same readable size. This page does that arithmetic for you, against the real metrics from each font file.
The spread is not academic. At the same contrast and the same weight, Source Serif 4 needs roughly 20px where Merriweather needs 17px — the same nominal requirement, a 17% difference in the size you must actually set. EB Garamond, with an x-height of 0.400 em, needs around 23px where Helvetica needs 18px.
What this page will not do
It will not let you upload a font file, and it will not convert or export one. Measurements derived from a typeface are facts about it; a converted or subsetted font file is a derivative work, and distributing one is the foundries' business rather than ours. You get metrics, previews and CSS — never font bytes.
It also will not guess. 48 families are excluded because their font files report no x-height, or one below 0.35 em, which is not credible for a text face. A missing measurement is reported as missing.
Questions people ask
Straight answers. Each one links directly: copy the address after opening it.
Why does the minimum size change when I change the typeface?
Because the letters change size. Two fonts set at the same nominal size put different amounts of ink on the page: what you read is the x-height, not the em box. APCA's lookup table is calibrated against a reference x-height of 0.52 em, so its answer only holds for fonts near that. Set the same size in a font with a smaller x-height and the text is physically smaller, which means the table's minimum is too small.
Is this adjustment something you invented?
No. It is in APCA's own specification, which says to divide the reference x-height by the x-height of the font you are using and multiply the minimum size by that factor. What is unusual is doing it automatically. Every contrast checker we could find reports the unadjusted number, and none of them asks which font you are using.
Where do the x-height figures come from?
From the OS/2 table inside each font file, via the Capsize metrics project. We ship 872 families. 48 more are left out because their files report no x-height at all, or report one so small it cannot be true for a text face. Guessing on their behalf would produce a confident number with nothing behind it.
Does this replace the WCAG 2 contrast ratio?
No, and the page shows both. WCAG 2 is what conformance is still measured against in most of the world, so you need it. APCA is the better predictor of whether text is actually readable, because it accounts for size and weight where WCAG 2 treats a 12px hairline and a 32px bold as the same problem. Where the two disagree, the disagreement is the interesting part.
Why does it also count characters per line?
Because size is only half of legibility. The usual rule of thumb divides the column width by half the font size, which is wrong by a wide margin for condensed and monospaced faces. This uses the average advance width from the font file, so the count reflects the typeface you actually chose.