PDF font inspector — embedded, subsetted, missing, and why a print shop cares about every distinction
Most users do not think about fonts inside a PDF until something goes wrong: text reflows on a colleague's screen, the print shop calls back asking about "missing fonts," or a regulatory submission gets rejected for non-compliance. By the time you notice, the document has already been distributed and the fix means going back to the source and re-exporting. The font inspector exists to catch font problems before distribution. Here is how PDF font references actually work, what "embedded" really means under the hood, and the three categories of font problem the inspector surfaces.
How PDFs reference fonts
Every text element in a PDF references a font by an internal name. The PDF's /Resources dictionary on each page lists which fonts that page uses, and each font reference points to a font dictionary somewhere in the document. The font dictionary has metadata — the font's PostScript name, its encoding, its FontDescriptor (with metrics like ascent / descent / bounding box). Critically, the FontDescriptor may or may not contain a /FontFile* entry — a stream of the actual font bytes.
If the FontFile is present, the font is embedded: the document carries the actual font bytes inside it, so any viewer can render it correctly regardless of what fonts the viewer's machine has installed. If the FontFile is absent, the font is referenced but not included: viewers have to find a matching font on the local machine, or substitute. That substitution is where things go wrong.
What 'embedded' really means
The inspector reports a font as embedded if the document carries its bytes. Three sub-cases worth distinguishing:
- Fully embedded. The complete font file is in the PDF. Every glyph the font defines is available, even glyphs not used in the document. File size is bigger but the document is fully portable.
- Subsetted. Only the glyphs actually used in the document are embedded. Identified by a 6-letter random prefix on the font name (e.g. ABCDEF+TimesNewRoman). Saves significant file size — typical fonts have 500-2000 glyphs, but a document might only use 80. Subset = those 80 only.
- Standard 14. The PDF spec defines 14 fonts (Helvetica, Times, Courier, Symbol, ZapfDingbats and variants) that are guaranteed to be present in every conformant PDF reader without embedding. Documents referencing only Standard 14 fonts can skip embedding entirely with no portability risk. Modern best practice embeds everything anyway.
Three font-problem categories the inspector surfaces
Each category has different downstream impact:
- Non-embedded non-Standard-14 fonts. The dangerous case. The PDF references a custom font but does not carry its bytes. Recipients without that font installed see a substituted font with different metrics — text reflows, page count may change, layout breaks. The inspector flags these in red.
- Non-embedded Standard 14 fonts. Acceptable per spec, but flagged with a yellow caution. Some workflows (print shops, PDF/A archives) require ALL fonts embedded regardless. If your destination workflow has that requirement, treat yellow as actionable.
- Embedded but not subsetted. Just an inefficiency flag, not a problem per se. The font is fully embedded so portability is fine, but the file is bigger than it needs to be. Re-export from source with subsetting enabled to shrink.
When font embedding really matters
Five workflows where non-embedded fonts cause genuine pain:
- Print production. Print shops universally require embedded fonts. Without them, the press substitutes whatever it has, which is rarely what the design intended. Reject-rate from print shops on this single issue is high.
- PDF/A archival. PDF/A explicitly requires all fonts embedded. A non-compliant PDF fails the validator before it ever reaches the archive.
- PDF/X print exchange. Same requirement for print-exchange formats. The spec is explicit.
- Cross-platform sharing. If your audience is mixed Windows / Mac / Linux, the chances of every viewer having every custom font installed is essentially zero. Embedding is the only fix.
- Long-term distribution. Fonts go out of print. A PDF from 2005 referencing a custom font that the manufacturer no longer ships cannot be rendered correctly today. Embedding makes the PDF self-contained for the long haul.
How to fix non-embedded fonts
Three paths, ordered by speed:
- Re-export from source with 'Embed all fonts'. The cleanest fix. Word, Google Docs, InDesign, LaTeX, every modern publisher has an embed-all option. Re-export, replace the PDF.
- Run through Acrobat Pro's font-embed pass. If you do not have the source, Acrobat Pro can embed fonts it finds on your machine. Only fonts installed on your machine can be embedded this way — if the original used a font you don't have, this doesn't help.
- Substitute the unembedded font with one you do have. Last resort. Edit the PDF in a tool that can remap font references. Results vary; the substitution may look fine or may look terrible depending on metric similarity.
Limits and compatibility
On the free web tool, font inspection handles PDFs up to 100 MB. Parsing runs in your browser via byte-level parsing; nothing is uploaded. Output lists every font with embed status, subset flag, encoding, page usage. Exportable as JSON / CSV for downstream auditing.
Common pairings: Font Inspector → re-export with embedding for distribution-ready PDFs. Font Inspector → PDF/A check to verify compliance after embedding. Font Inspector → Compress for the smallest fully-embedded final file.