Your files never leave your device. All processing happens locally in your browser.
How do I test whether a font size, line-height and line length are readable?
Open the Font Size Tester, set a font size, line-height, weight and container width, and it renders a live, editable specimen in a system font stack, then grades it: it converts px to rem against your root size, estimates the readable “measure” (characters per line ≈ container width ÷ (size × ~0.5em)) and flags it against the comfortable 45–75 character band, and runs the practical WCAG checks — a 16px body baseline, the 1.5× line-height floor for body text (SC 1.4.12) and the 200% resize / prefer-rem reminder (SC 1.4.4). You can also anchor a modular scale on the size, compare common sizes side-by-side, and copy the result as CSS (px + rem), a fluid clamp() or the whole scale. Everything runs in your browser — nothing is uploaded.
Live editable specimen in system font stacks — no web fonts fetched
px↔rem conversion against a configurable root size (16px default)
Measure grade: characters per line vs the comfortable ~45–75 band
Anchor a modular scale (base × ratio raised to the step) and export CSS / clamp() / scale vars
100% client-side — guidance, not a formal audit
What is
Font size testing (typographic size & measure evaluation)
Font size testing is the practice of choosing and evaluating a body or heading font size together with its line-height and the line length (the “measure”) to judge readability. Size is set in px but is best authored in rem, a unit relative to the root font size (16px by default), so it honours the reader’s browser preference and survives 200% zoom (WCAG SC 1.4.4). The measure — characters per line — is estimated from the container width divided by an average glyph advance (~0.5em for proportional Latin, ~0.6em monospace); the widely-cited comfortable range is about 45–75 characters, with ~66 the classic ideal. Line-height should reach about 1.5× the font size for body copy (WCAG SC 1.4.12). A modular scale can derive a whole system from a base as size = base × ratio raised to the step index.
Design
Related terms
font sizeline-height (leading)measure (line length)characters per linerempx to remroot font sizex-heightmodular scaleCSS clamp()fluid typographyWCAG 1.4.4 Resize textWCAG 1.4.12 Text Spacingreadability
Frequently Asked Questions
No. Your size, line-height, container width, ratio and the specimen text are just numbers and strings held in the page, and every calculation runs locally in your browser. There is no upload, no server and no CDN in the path, and nothing is stored.
The tester is 100% client-side. The px↔rem conversion, the characters-per-line estimate, the modular scale and every clamp() string are computed by pure functions in your tab, and the preview is ordinary text your browser renders with SYSTEM fonts — so not even the specimen font is downloaded. Nothing you type or set is transmitted: there is no upload endpoint, no server-side processing and no CDN involved. The tool works offline once cached, and closing the tab discards your text and settings.
A common baseline is 16px (1rem) body text with a line-height around 1.5, and a line length of roughly 45–75 characters (about 66 is the classic ideal). These are guidance, not hard rules — the right size depends on the typeface, audience and device.
For body copy, about 16px is the widely-used baseline (WCAG sets no hard minimum, but small text hurts low-vision readers), authored in rem so it respects the reader’s browser preference. Line-height around 1.5 keeps lines from crowding (SC 1.4.12 requires body text to survive 1.5× when forced). The measure — characters per line — reads most comfortably at roughly 45–75 characters, with ~66 the classic ideal; shorter lines feel choppy and longer lines make it hard to find the next line. All of these are guidance: a typeface with a large x-height reads bigger than its point size suggests, and the ideal shifts with language, audience and viewing distance, so test with real content.
Prefer rem for font sizes. rem is relative to the root font size, so it scales with the reader’s browser preference and survives 200% zoom (WCAG SC 1.4.4). Fixed px sizes ignore that preference. This tool shows both so you can copy the rem value.
rem (root em) is relative to the document’s root font size — 16px by default, but the reader can raise it for accessibility — so rem-based type scales automatically with that preference and keeps content readable at 200% zoom, which is the WCAG 1.4.4 requirement. Fixed px sizes are absolute and ignore the reader’s setting, so they are riskier for accessibility. The tester converts your px value to rem against a root size you control and exports the rem value (and an optional fluid clamp() that combines rem and viewport width so type also scales with the screen). If your project changes the root font size, re-check the conversions.
It is an estimate, not an exact count. It divides the container width by an average glyph width (~0.5em proportional, ~0.6em mono), but real fonts, weights, languages and x-heights differ, so treat the number and its grade as guidance and verify with real copy.
The measure is computed as container width divided by an average glyph advance — roughly 0.5em for proportional Latin text and 0.6em for monospace. Real fonts vary a lot: a condensed face fits more characters per line than a wide one at the same point size, bold weights are wider, and non-Latin scripts differ entirely. x-height also matters — two fonts at the same size can look very different in apparent size and density. So the characters-per-line figure and its tight / ideal / loose grade are guidance to get you into the comfortable 45–75 band quickly, not a pixel-exact measurement; always confirm with your actual typeface and content.
Detailed Explanation
⚙️Methodology
How the Font Size Tester Works
The tester renders a live, editable specimen at your chosen font size, line-height, weight and container width using a SYSTEM font stack (no web fonts are fetched), then grades it with a pure engine (typeScaleEngine.ts). It converts the px size to rem against a configurable root size (size ÷ root), suggests a line-height (looser ≈1.5 for body, tighter toward 1.1 for display), and estimates the readable “measure” as characters per line ≈ container width ÷ (size × average glyph width). It also anchors a modular scale on the size (size = base × ratio^step) and builds a fluid clamp() by linear interpolation between viewport widths. Every value is computed in the browser as plain numbers — nothing is uploaded.
Live specimen in system font stacks — no web fonts downloaded
px → rem against a configurable root size (16px default)
Suggested line-height and a modular scale (base × ratio^step)
All maths run client-side; nothing is uploaded or stored
📖How It Works
The Measure — Characters Per Line
The “measure” is the number of characters on a line, the single biggest driver of comfortable reading after size itself. The widely-cited comfortable band is about 45–75 characters, with roughly 66 the classic ideal for body copy. Lines shorter than ~45 characters force the eye to jump too often and feel choppy; lines longer than ~75 make it hard to track back to the start of the next line. Because measure depends on both font size and container width, the tester estimates it from container width divided by an average glyph advance and grades it tight / ideal / loose, updating live as you drag either slider so you can find a size and column width that read well together.
Comfortable line length is ~45–75 characters (≈66 ideal)
Too short (<45) feels choppy; too long (>75) is hard to track
Measure depends on BOTH font size and container width
Estimated from width ÷ average glyph advance, graded live
Guidance for body copy — headings and captions differ
🔧Technical Details
px vs rem and the 200% Resize Rule
Font sizes are best authored in rem rather than px. A rem is relative to the root font size (16px by default), so rem-based type scales automatically when a reader raises their browser’s default size and keeps content readable at 200% zoom — the actual WCAG requirement (SC 1.4.4 Resize text), since WCAG mandates no hard MINIMUM font size in pixels. Fixed px sizes ignore that preference and are riskier for low-vision users. The tester shows both the px and rem value for the size you test against a root you control, and can emit a fluid clamp() that combines rem with viewport width so type also scales with the screen without media queries.
rem is relative to the root font size (16px default)
rem honours the reader’s browser preference; px does not
WCAG SC 1.4.4 requires text to survive 200% zoom — no hard px minimum
Tool shows px and rem for every tested size
Optional clamp() combines rem + viewport width (no media queries)
📋Use Cases
Practical WCAG Checks for Body Text
For body copy the tester surfaces the checks that actually matter: a ~16px baseline (WCAG sets no hard minimum, but small paragraph text hurts low-vision readers — small text is fine only for captions and labels); a line-height of at least 1.5× the font size, the floor WCAG SC 1.4.12 Text Spacing requires body text to withstand when a reader forces it; and the 200% resize / prefer-rem reminder from SC 1.4.4. These are shown as plain guidance with pass / warn / info states, deliberately NOT as a green “compliant” badge, because true conformance also depends on the typeface, colour contrast, spacing, real content and actual users.
~16px body baseline (WCAG sets no hard pixel minimum)
Line-height ≥ 1.5× for body text (SC 1.4.12 Text Spacing)
Text must survive 200% zoom (SC 1.4.4) — prefer rem
Shown as guidance (pass / warn / info), not a compliance badge
Real conformance also needs contrast, spacing and real testing
⚠️Limitations
Estimates and Honest Limits
The characters-per-line figure is an ESTIMATE from an average glyph width (~0.5em proportional Latin, ~0.6em monospace) — real fonts, weights, languages and x-heights differ, so the measure and its grade are guidance, not a pixel-exact count. Two fonts at the same point size can look very different because x-height, not point size, drives apparent size. Modular scales multiply by a ratio and so yield fractional pixels (25px, 31.25px…) that browsers round differently, and the rem values assume the root size you set. The tool tests SIZES and LEADING; it does not embed or choose fonts, judge a real typeface’s legibility, or audit a full design system. Verify with real content, on real devices, with real readers.
Characters-per-line is estimated, not an exact count
x-height drives apparent size more than point size
Modular scales yield fractional px that browsers round
rem values assume the root size you configure
Tests size & leading only — not font choice or full audits
🔒Privacy & Security
Private by Design
Everything happens on your device. Your font size, line-height, letter-spacing, container width, weight, ratio, root size and the specimen text are held as ordinary state and transformed by pure functions in the page — the px↔rem conversion, the measure estimate, the modular scale and every clamp() string are computed locally. The preview is plain text your browser renders with system fonts, so not even the specimen font is downloaded, and the CSS export is a local data-URL. There is no upload endpoint, no server-side processing and no CDN in the path; the tool works offline once cached, keeps no accounts, sets no tracking, and discards everything when the tab is closed.
All calculations run in the browser as plain numbers/strings
Preview uses system fonts — no web font download
No upload endpoint, no server-side processing, no CDN
CSS export encoded locally and downloaded in-memory
Works offline once cached; no accounts, no tracking
Font-size units and readability guidance surfaced by the tester
Concept
What it means
Guidance / rule
px
Absolute pixels; ignores the reader’s browser setting
Fine for previewing; risky as the authored unit for body text
Line length in characters, from width ÷ glyph advance
Comfortable ~45–75; ≈66 ideal for body copy (estimate)
Line-height
Leading as a multiple of the font size
Body text should reach ≥ 1.5× (SC 1.4.12); display can be tighter
Body font size
Size of running paragraph text
No hard WCAG minimum; ~16px is a common, safer baseline
Character-per-line figures are estimates from an average glyph width; real fonts, x-heights and languages vary. Guidance, not a formal audit. As of July 2026.
