PDF Font Embedding
PDF font embedding is the process of including the complete or subsetted font program inside a PDF file so that text renders identically on any device, regardless of whether the recipient has the font installed. Embedded fonts are stored in the PDF's resource dictionary and referenced by page content streams.
PDF font embedding is the process of including the complete or subsetted font program inside a PDF file so that text renders identically on any device, regardless of whether the recipient has the font installed. Without embedding, a PDF viewer must substitute a locally available font when the original is not present — causing glyph substitution, changed character spacing, and text reflow that can make the document unreadable or non-compliant.
Embedded fonts are stored in font stream objects within the PDF's object structure, referenced from the font dictionary in each page's resource dictionary. ISO 32000 defines font embedding requirements for all four PDF font types: <strong>Type 1</strong> (PostScript CFF/PFB outlines), <strong>TrueType</strong>, <strong>OpenType (CFF)</strong>, and <strong>Type 3</strong> (custom glyph drawing programs). <a href="https://pdftheguide.com/glossary/pdf-a" target="_blank" rel="noopener">PDF/A</a> mandates full embedding for all fonts used in a document.
How font embedding works in the PDF structure
A PDF font resource is represented by a font dictionary object containing:
<strong><code>/Type /Font</code></strong> — Identifies the object as a font. <strong><code>/Subtype</code></strong> — The font technology: <code>/Type1</code>, <code>/TrueType</code>, <code>/CIDFontType0</code> (CFF CIDFont), <code>/CIDFontType2</code> (TrueType CIDFont), <code>/Type3</code>. <strong><code>/FontDescriptor</code></strong> — A dictionary describing the font's metrics and visual characteristics, with a key entry: the font stream reference. <strong><code>/FontFile</code></strong> (Type 1), <strong><code>/FontFile2</code></strong> (TrueType), or <strong><code>/FontFile3</code></strong> (CFF/OpenType) — The actual font program, stored as a stream object in the PDF.
When a PDF viewer encounters a text-rendering operator referencing this font, it uses the embedded font program to generate glyph outlines. No system font lookup is needed.
<strong>Subsetting indication</strong> — When a font is subsetted (only used glyphs embedded), the <code>/BaseFont</code> name in the font dictionary is prefixed with a six-character tag followed by a plus sign: e.g., <code>/ABCDEF+Helvetica</code>. The prefix must be six uppercase letters and is typically random. Any PDF processing tool seeing this prefix knows the font is a subset, and that the full glyph set is not available.
<strong>Resource inheritance</strong> — Fonts are registered in page resource dictionaries (<code>/Resources /Font</code>). In PDFs with many pages using the same fonts, the font dictionary can be inherited from a page tree node to avoid repetition, though embedded font stream data is always shared via indirect object references.
The /ToUnicode CMap
The <code>/ToUnicode</code> entry in a font dictionary is a CMap stream that maps the glyph identifiers (character codes) used in the content stream to Unicode code points. It is separate from the font's encoding (which maps character codes to glyph names) and from the font's actual glyph outlines.
<strong>Why /ToUnicode is critical</strong>: - <em>Text extraction</em>: PDF text extraction tools, copy-paste, and search functionality all rely on /ToUnicode to convert what the PDF viewer renders as glyphs back into the underlying Unicode characters. Without /ToUnicode, extraction produces either empty text or incorrect characters. - <em>Accessibility</em>: Screen readers and assistive technologies read extracted text. A PDF without /ToUnicode maps will appear to contain no text or gibberish to a screen reader. - <em>Reflow and search</em>: Reflow-mode PDF viewers (including many mobile readers) reconstruct text flow from extracted text — no /ToUnicode, no reflow. - <em>PDF/UA requirement</em>: <a href="https://pdftheguide.com/glossary/pdf-ua" target="_blank" rel="noopener">PDF/UA</a> requires that all text (non-artifact content) has a Unicode mapping, which requires proper /ToUnicode maps.
<strong>Ligatures and common failures</strong>: Professional OpenType fonts use ligature substitution (fi, fl, ffi combinations rendered as single glyphs for typographic quality). If the /ToUnicode map for the ligature glyph is missing or maps to a placeholder, extracting text from the PDF will produce "file" (ligature character) instead of "file" — a very common PDF quality issue in high-quality typography PDFs.
<strong>CJK and composite fonts</strong>: CIDFont dictionaries (used for CJK and Unicode-range fonts) use ToUnicode CMaps that map CID (Character IDentifier) values to Unicode. For CJK content, ToUnicode is especially critical because the character set is so large that extraction failure affects entire documents.
PDF/A, PDF/UA, and font embedding requirements
<strong>PDF/A requirements</strong>: All three PDF/A variants (PDF/A-1, PDF/A-2, PDF/A-3) require: 1. All fonts used in the document must be embedded (no non-embedded fonts). 2. All embedded fonts must have /ToUnicode maps for non-symbolic content. 3. Symbolic fonts (Symbol, ZapfDingbats) must use the correct predefined encoding.
PDF/A does not require subsetting or non-subsetting specifically — either is acceptable. However, subsetted fonts are the norm in practice.
<strong>PDF/UA requirements</strong>: PDF/UA (ISO 14289) requires that all text content (non-artifact) has a Unicode mapping. This effectively requires /ToUnicode maps for all text fonts used in content. Additionally, PDF/UA requires that glyph widths in the font dictionary match the actual rendered glyph widths, to ensure correct text spacing for assistive technologies.
<strong>Common validator failures</strong> — The most common font-related PDF/A and PDF/UA validation failures: - Font not embedded (not in the file) - /ToUnicode missing for non-symbolic content - Glyph in content stream not in the embedded font subset - /FontDescriptor missing required fields - Encoding inconsistency between font dictionary and CMap
<strong>Fixing font issues</strong>: The most reliable fix is to re-export from the source document with font embedding and ToUnicode generation enabled. Post-hoc fixes require the original font to be installed and are less reliable.
Frequently asked questions
How do I check whether fonts are embedded in a PDF?
In Adobe Acrobat (free Reader or Pro): File > Properties > Fonts tab. Each font listed shows either "(Embedded Subset)" — correctly embedded with subsetting — or "(Embedded)" — fully embedded without subsetting — or neither of those labels, meaning the font is not embedded. The command-line tool pdffonts (part of Poppler, available on macOS via Homebrew: brew install poppler) produces a tabular listing of all fonts with columns showing whether each is embedded and whether a ToUnicode map is present. Run: pdffonts document.pdf. The emb column shows "yes" for embedded fonts. The uni column shows "yes" for fonts with ToUnicode maps. Both should be "yes" for a PDF/A or accessible PDF.
Can I embed fonts in an existing PDF after it was created?
Yes, in some cases. Adobe Acrobat Pro: Print Production > Preflight > Fixups includes a "Embed missing fonts" fixup. This works only for fonts that are installed on the machine running Acrobat. If the original font is not installed, Acrobat cannot embed it. Ghostscript can also attempt font embedding: gs -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -dEmbedAllFonts=true -sOutputFile=out.pdf in.pdf — this uses fonts from Ghostscript's font search path. Neither approach can embed a font you don't have. If the font is proprietary (licensed), you need to have a valid font license that permits embedding before embedding it. The most reliable approach for missing-font problems is to fix the source document workflow to always embed fonts on initial PDF creation.
What happens when a font is embedded in a PDF but /ToUnicode is missing?
When a font is embedded (so text renders correctly visually) but /ToUnicode is missing, the PDF looks correct but text cannot be extracted, copied, or read by assistive technology. Specifically: (1) Selecting and copying text from the PDF pastes empty text or garbled characters; (2) Ctrl+F search within the PDF finds nothing; (3) Screen readers read nothing or garbled content; (4) AI and text extraction tools produce empty or incorrect output; (5) PDF/A and PDF/UA validators flag the missing ToUnicode as a conformance failure. This is a common problem with PDFs generated from PostScript by older Distiller configurations, some non-Adobe PDF creators, and PDFs produced from legacy applications that didn't add ToUnicode maps. The fix requires re-processing with a tool that generates ToUnicode maps, which typically means re-exporting from source.