Upload the file here. Every font family is listed with its embed status — embedded, subset, not embedded, or could not verify — along with the pages it is used on and a print-readiness score. Developers can get the same core answer from the pdffonts command in Poppler.

It means the font is embedded, but only the glyphs your document actually used are stored rather than the complete typeface. It is normal, it is what keeps PDFs small, and it is accepted by PDF/X and PDF/A workflows. A subset is embedded — the panic it causes is almost always misplaced.

The PDF asks the reading machine for a font it may not have, so the viewer or the printer substitutes the closest match it can find. Substitutes rarely share the original character widths, so spacing shifts, lines rewrap and the page you approved is not the page that prints.

Almost always a font that is not embedded. Your machine has the font installed, so the file looks correct to you; another machine does not, so it substitutes. This is the single most common cause of a PDF that changes between the person who made it and the person who opens it.

The file structure did not give enough evidence to say either way — usually a font stream that could not be read. It is reported as its own outcome rather than being rounded down to “not embedded” or up to “embedded”, because guessing in either direction would be misleading.

Yes. PDF/X is built for reliable print exchange, so every font used must travel inside the file. Fonts may be embedded either in full or as subsets — full embedding is not generally required, which is worth knowing before anyone re-exports a document unnecessarily.

Yes. An archival PDF has to be self-contained so it still renders decades from now, when the fonts it references may not exist anywhere. PDF/A also expects the fonts to be legally embeddable for unrestricted rendering, which is a licensing question as much as a technical one.

Frequently, yes — it is one of the most common preflight rejections, because the shop cannot guarantee output for a font it does not have. Check before you send rather than after, since a rejection usually costs a day and a re-export you could have done yourself.

The major print-on-demand platforms require or strongly recommend it for interiors and covers, and files are commonly rejected on this exact point. Confirm every font reports as embedded or subset before uploading, and treat “not embedded” as a blocker rather than a warning.

Many do. Several US court filing systems explicitly require or strongly recommend embedded fonts, and university thesis and repository guidance routinely requires them so documents render consistently for every future reader. Check the specific rule that binds you, since the requirements are not uniform.

Yes, and this is the part most tools skip. Embedding supplies the glyph shapes for rendering, while copying, searching and extraction depend on encoding and Unicode mapping. A file can display perfectly and still copy as gibberish, because those are two different mechanisms.

Usually a missing glyph rather than a missing font. The embedded subset may not contain the character you need — most often an accent, a symbol, or a non-English character that was added after the original export. The font name looks fine; the specific shape is not there.

Because the PDF lacks a dependable map from its internal character codes to Unicode. Custom encodings and a missing or malformed ToUnicode map produce text that renders correctly and extracts as nonsense. Embedding does not fix this — the mapping has to be right too.

A composite font addressed by character IDs rather than single bytes, used for large character sets such as CJK and for most modern embedded fonts. When CID data is missing or invalid the failures are especially confusing, because the file can look correct while extracting and printing badly.

Because font files carry an embedding-permission flag set by the foundry, and some licences forbid it outright. Owning a licence to use a font is not the same as holding the right to embed it, which is why applications sometimes refuse to include one and substitute instead.

Because font embedding has to be turned on in the export settings, and even then it is unreliable for OpenType/CFF and variable fonts. Enable “Embed fonts in the file”, re-export, and then verify the result here rather than assuming it worked.

Those export paths substitute fonts the environment does not have, and they make that decision silently. Anything going to print or to a formal submission is safer exported from a desktop application with embedding enabled, then checked before it leaves your hands.

Only as a last resort, usually when licensing blocks embedding. Outlining guarantees appearance but removes searchable, selectable and accessible text, inflates the file, and makes future edits impossible. Embed where you can and outline only the handful of characters where you cannot.

Re-export whenever you still have the source document. Setting embedding correctly at export takes a moment and fixes every font at once, while patching an existing PDF is fiddly and can introduce new encoding problems. Remediate the PDF only when the source is genuinely gone.

Full embedding can, especially for large character sets. Subsetting is the reason it usually does not — only the glyphs in use are stored, which is why a typical subsetted PDF carries its fonts for a few tens of kilobytes rather than megabytes.

No. It is a read-only checker — your file is inspected and never modified. Fix the embedding where the document was made, or with a preflight tool that has the fonts installed, then re-upload here to confirm it worked.

Only what the font program itself declares about its own embedding permissions. It cannot read your licence agreement or tell you whether a particular commercial use is permitted — for that, check the foundry’s terms.

The PDF is sent over an encrypted connection, inspected read-only, and removed afterwards. It is not stored, shared, indexed or used to train models, and no account is required.