What font metrics tell you
Every font file contains a set of internal measurements that tell the rendering engine how to lay it out: ascent (height above the baseline), descent (depth below), x-height (height of lowercase x), cap-height (height of uppercase letters), units-per-em (the design grid resolution). These numbers are stored in the OS/2 and hhea tables of the font binary and accessed by browsers when rendering and by you when configuring fallbacks.
Two fonts at the same CSS font-size can look very different sizes because their internal metrics differ. The Inspector here parses the font binary in the browser and surfaces these numbers in a readable form. Knowing your font ex-height ratio (sxHeight divided by unitsPerEm) is what powers the font-size-adjust property and what makes layout-shift-free font swaps possible.
Variable font axes
If the font is a variable font, the Inspector also reads the fvar table to list every axis the font exposes: name, tag, min value, max value, default value. The five registered axes (wght for weight, wdth for width, opsz for optical size, slnt for slant, ital for italic) appear with their friendly names. Custom axes (GRAD on Roboto Flex, MONO and CASL on Recursive, SOFT and WONK on Fraunces) appear with their tag names.
This is useful when you receive a variable font from a designer and need to know what controls are available without opening it in a font editor. The Inspector also reports named instances if the font defines them: pre-baked locations on the variation space like Light, Regular, Bold.
Common Use Cases
Developers integrating a brand font use the Inspector to extract the metrics that feed @font-face descriptors: size-adjust, ascent-override, descent-override, and line-gap-override. Plug those into the @font-face block and the font behaves the same on every browser, with predictable line-heights and zero metric drift.
Performance engineers use the Inspector to compare file sizes across formats: the TTF, the WOFF, and the WOFF2 of the same font report different bytes-on-disk. Picking the smallest format that still ships everywhere your audience uses (WOFF2 plus a WOFF fallback for ancient browsers) saves real bandwidth.
How We Compare
Command-line tools like fontTools and pyftinspect produce the same data but require Python and a terminal. The Inspector runs in the browser, displays metrics visually with units overlaid on glyphs, and lets you copy any field with one click. No install, no setup.
Compared to opening the font in Glyphs or FontLab, the Inspector is read-only and focused on the metrics that matter for web use. You will not edit glyphs here. The trade-off is that you also will not be surprised by a destructive operation, and the Inspector covers exactly what you need to know to ship the font on the web.
Frequently Asked Questions
What is units-per-em?
units-per-em (often abbreviated UPM) is the design grid resolution of the font. Every glyph and metric inside the font is expressed in this unit. The CSS engine scales the entire grid to match the font-size you specify. A font with UPM 1000 designed for a 100-pixel glyph that should appear at 50-pixel font-size is automatically scaled. The Inspector reports UPM because it is the denominator in every other ratio you might want.
What is the difference between ascent and cap-height?
Ascent is the height the font designer reserved for any glyph in the font, including diacritics and accents above capitals. Cap-height is the height of the unaccented uppercase letters themselves. The difference is the space above the caps for hats and umlauts. For layout math, cap-height is usually more useful because it represents what users actually see when reading.
What does sxHeight in the OS/2 table mean?
sxHeight is the field that records the height of the lowercase x in design units. Divide it by unitsPerEm to get the ex-height aspect ratio. This is the value you use with font-size-adjust. Some old fonts have sxHeight set to zero (the designer did not fill it in). The Inspector measures the actual x glyph in that case and computes a value, flagging that it was measured rather than declared.
Can I see the glyph table?
Yes. The Inspector includes a grid view of every glyph in the font, paginated. Hover over a glyph to see its name, Unicode code point, advance width, and bearing values. Use the search bar to jump to a specific letter or symbol. This is the same kind of view font editors offer, scaled to the web for quick inspection.
Does this work with WOFF2?
Yes. The Inspector includes a Brotli decompressor (wawoff2) loaded from a CDN, so WOFF2 files are decompressed in the browser before being parsed. The decompressor is loaded on-demand, only when you upload a WOFF2 file, so the page load cost is paid only by users who need it.
How accurate are the measured metrics?
Exact, to the precision of the font binary. Most metrics are declared as integers in the font tables and the Inspector reads them as-is. For metrics that are computed (like ex-height from the actual x glyph bounding box when sxHeight is zero), the Inspector reports them to four decimal places. Any rounding is documented in tooltips.
What about kerning data?
The Inspector reports whether the font has a kern table or GPOS positioning rules, and the count of kern pairs. The actual per-pair adjustments are not shown by default because the volume is overwhelming for most fonts (5000+ pairs is common). A detail panel lets you query specific pairs like AV or To by typing them in.
Can I export a font metrics file for build automation?
Yes. The Inspector exports a JSON object with every metric, every variable axis, and the file size in each format. CI scripts can consume this to verify that a new font version has not changed metrics unexpectedly, which would otherwise quietly break layout in production.