Embed fonts in your PDF. It isn't a printing setting — it's an accessibility one.

In the 59 Word-exported public-sector PDFs we validated for an earlier piece on this same crawl, clause 7.21.4.1-1 — fonts not embedded — failed in 64% of them. It was the third most common failure in that sample, and the only one of the top three that Word actually lets you fix with a checkbox.

What "not embedded" means for the person listening, not the person printing

Every letter a PDF displays is stored as a numeric character code tied to a font, not as a literal Unicode character. Something has to translate "this glyph, in this font, at this position" back into "the letter T" before a screen reader, a search box, or a copy-paste operation can do anything with it. A PDF can carry that translation explicitly, in a lookup table called a ToUnicode CMap. When it's present, extraction is unambiguous no matter what font is or isn't installed on the reading machine. When it's absent, the reader falls back on the font's own internal encoding — which only works if the actual font, or something that behaves identically to it, is available to consult. Strip the font out of the file and you've removed exactly the thing that fallback depends on.

Which fonts go missing, and what goes missing with them

The two fonts responsible for nearly all of it

Of the 38 files in our sample that fail 7.21.4.1-1, we read the font name out of every failing check veraPDF reported. Two families account for almost the entire problem:

(Files can be missing both, so the shares don't sum to 100%.) These are the two fonts every Windows installation already has, which is exactly the trap: they render correctly on the machine that made them, so nobody notices anything is wrong until the file reaches a device — or an assistive technology — that substitutes something else.

Whether the file gives anyone a fallback

We then checked whether these files carry the ToUnicode table that would soften the blow. Using pikepdf against all 38 files, we counted every distinct non-embedded font object — 144 of them, which lines up with veraPDF's own failed-check count for the same clause — and asked whether each one had a ToUnicode CMap: none of the 144 do.

In practice, extraction still worked here. We ran the same 38 files through pdfplumber, and the Hungarian text — including the double-acute vowels ő and ű, which don't exist in a plain Windows-1252 code page — came out correctly, because pdfplumber's own decoder already knows the standard /WinAnsiEncoding table every one of these 144 fonts declares, whether or not a ToUnicode table backs it up. So nobody's copy-paste broke today. What's missing is the guarantee: the file makes no promise of its own about how its text should be read, and hands that job entirely to whichever tool happens to open it next. PDF/UA doesn't let a producer rely on that, and after checking 144 of these font objects without finding one counterexample, neither would we.

uv run --quiet python3 -c "
import pikepdf
pdf = pikepdf.open('file.pdf')
for page in pdf.pages:
    for font in page.get('/Resources', {}).get('/Font', {}).values():
        fd = font.get('/FontDescriptor')
        if fd and not any(k in fd for k in ('/FontFile', '/FontFile2', '/FontFile3')):
            print(font.get('/BaseFont'), '- ToUnicode:', '/ToUnicode' in font)
"

Does this get better with a newer Word? We checked, and no

It would be a tidy ending if the failure rate simply fell as Word got newer. Grouped by the Producer field in each file's metadata, across the 54 of our 59 files actually produced by a version of Word itself:

Read this as a trend and you'd conclude Microsoft has been quietly fixing the default. Read the sample sizes and that conclusion falls apart: the two most recent versions cover two files and one file. That's not evidence of anything — it's too little data to have an opinion about, and pretending otherwise is precisely the kind of overreach this kind of measurement exists to catch, not produce. If you want to know what your own installation defaults to, the test in the next section is the only one that actually tells you.

The fix is one checkbox, and it belongs in the template

In Word: File → Options → Save → Embed fonts in the file. Turn it on and the setting applies to the document you currently have open — which is the trap. It isn't machine-wide, so a new document, or a colleague on a different computer, starts from it unchecked again. The only way this survives past one lucky file is to build it into the template everyone actually opens from, not a step you remember on export day.

Word's own description of the setting is quietly conditional: it saves the fonts used in the document, "if the fonts are allowed to be embedded". Times New Roman and Arial — the two fonts doing almost all of the damage in this sample — carry Microsoft's standard embedding licence, so that condition is never an obstacle here. It can be one for anything you licensed separately: some commercial and free fonts ship with an embedding restriction baked into the font file itself, and no export setting overrides a licence the font doesn't grant.

Ticking the box reveals a second one: Embed only the characters used in the document. Leave it on. It doesn't reduce what a validator or a screen reader gets — a subset still embeds the exact glyph outlines the document actually draws, which is all either of them will ever ask for — it just avoids carrying the roughly one thousand glyphs of a full font that the document never uses. We checked this against our own corpus: where these same 59 documents did embed a font, 229 of the 337 distinct embedded font objects (68%) carried the six-character subset prefix Word stamps on a trimmed font — BCDEEE+Calibri, for instance — and not one of them tripped the embedding check. Subsetting is already the normal case in this dataset, not a compromise.

The one place subsetting does cost you something: if a different tool later edits a subsetted PDF and tries to add text in that font, there's no glyph data for the new characters to draw from. That's a real limitation — it just doesn't apply to publishing a document you aren't going to hand to a PDF editor afterwards, which is what a template setting is for.

What embedding doesn't fix

Font embedding earns its place as the fix everyone can actually make, but it is one fix among several, and it's worth saying plainly that it isn't the biggest one. In the same sample, the PDF/UA identifier (71% of files) and the document title in the metadata stream (68%) both fail more often than embedding does — and Word has no setting for either. Turning on font embedding will not touch those. It also won't rebuild a document that lost its structure entirely to a compression pass after export, which is its own failure mode worth checking separately if anything in your workflow runs after Word.

If you want to check your own documents

Word's Accessibility Checker will never flag a missing font — it isn't one of the seven things it looks at, by design, because it checks the document you wrote, not the file Word writes out. The only way to know is to look at the PDF itself. Our PDF accessibility checker reports the same clause veraPDF does on any file you upload, without installing anything; the PDF/UA error reference explains what each failure means and which ones a template setting actually prevents; and the PDF/UA guide covers what the standard requires beyond this one clause. Start with a document people actually download — Times New Roman and Arial are doing most of the damage, and they're in almost everything your office publishes.