Why does a PDF render perfectly but extract as garbage?

Rendering only needs a font's glyph shapes, all of which are present even in a subsetted font. Reading text back out needs a separate /ToUnicode map, and subsetting doesn't always regenerate it. When it's missing, extraction has nothing reliable to translate character codes into.

Can I fix a missing ToUnicode map after the file is created?

Not from the output text alone. The original glyph identity generally can't be recovered from it. Re-exporting from the source with a font that writes ToUnicode, or reading the rendered page instead of its codes, are the two practical routes.

Font subsetting

Embedding only the glyphs a PDF actually uses instead of a whole typeface, which shrinks files but can leave out the character-to-Unicode map extraction needs.

definition

Font subsetting is the practice of embedding only the specific glyphs a document actually uses from a typeface. It embeds those glyphs instead of the complete font file, to reduce PDF file size.

Also called: subsetted font, embedded subset font

in-plain-terms

A typeface can contain thousands of glyphs. A given document might use a few hundred. Subsetting strips a font down to just those, cutting file size substantially. It's standard practice for any PDF producer that embeds fonts rather than relying on the reader having them installed.

The catch is /ToUnicode, a separate table mapping each glyph back to a Unicode character. Subsetting the glyphs doesn't require regenerating that map, and some producers skip it. The page renders perfectly, since glyph shapes are all there. But extraction reads the map instead of the shapes, so it has nothing reliable to translate character codes into.

why-it-matters

A missing /ToUnicode map on a subsetted font is the single most common cause of a PDF that renders fine but extracts as garbage. It comes out as boxes, question marks, or (cid:N)-style tokens.
There's no reading-side fix for a missing map. The original glyph identity generally can't be recovered from the output text alone. The practical fix is reading the rendered page, with OCR or a vision-model pass, instead of the character codes.

how-to-check

The PDF text-layer checker's structural scan flags a Type0/Identity-H font with no ToUnicode map directly. It's the one case the checker can be certain about from structure alone. Check a PDF's font encoding

related-terms

faq

Why does a PDF render perfectly but extract as garbage?: Rendering only needs a font's glyph shapes, all of which are present even in a subsetted font. Reading text back out needs a separate /ToUnicode map, and subsetting doesn't always regenerate it. When it's missing, extraction has nothing reliable to translate character codes into.
Can I fix a missing ToUnicode map after the file is created?: Not from the output text alone. The original glyph identity generally can't be recovered from it. Re-exporting from the source with a font that writes ToUnicode, or reading the rendered page instead of its codes, are the two practical routes.

related-reading

PDF & scans

See the term in real output.

Drop a file into the free reader and watch it happen.

Open the file reader →

Get an API key →