How to subset fonts in a pdf to reduce file size
- Step 1Open the PDF Font Subsetter — Go to the PDF Font Subsetter. Everything runs locally — pdf-lib, pdfjs, and fontkit are loaded into the browser tab; nothing is uploaded to a server.
- Step 2Drop in a single PDF — This tool takes one PDF at a time (no batch on the free tier). Free tier accepts files up to 2 MB and 50 pages; Pro raises the cap to 50 MB and 500 pages. If your file is larger, compress it first or upgrade.
- Step 3Press Process — There are no options to configure. The tool scans every page's text content for used codepoints, analyses each embedded font with fontkit, and re-saves the document with packed object streams. Larger documents take longer because each page's text content is parsed in the browser.
- Step 4Read the result tiles — The result panel shows Input pages, Input size, Output size, and that processing was done in the browser. Compare Output size against Input size to confirm the reduction.
- Step 5Download the optimised PDF — Save the rebuilt file. The text, page layout, and
ToUnicodemapping are preserved, so search and copy/paste keep working. - Step 6Stack with a compressor if you need more — If most of your file is images rather than fonts, run lossless compression to keep text selectable, or lossy compression when image size dominates and you can accept rasterised pages.
What this tool touches and what it leaves alone
The processing pipeline, step by step. Anything not listed in the first column is passed through unchanged on the object-stream re-save.
| Stage | What happens | Effect on output |
|---|---|---|
| Codepoint scan (pdfjs) | Every page's text content is read; each character's codepoint is added to the used set, plus the full ASCII range 0x20–0x7E | Determines which glyphs are considered 'in use' |
| Font analysis (fontkit) | Each embedded FontFile/FontFile2/FontFile3 is parsed and a subset is computed from the used glyphs | Confirms which fonts are real OpenType/TrueType programs |
| Document rebuild (pdf-lib) | The whole PDF is re-saved with useObjectStreams: true — cross-reference and object structure repacked | This is where the measurable byte reduction comes from |
| Text + ToUnicode | Page content streams and Unicode maps are preserved on the round-trip | Search, copy/paste, and accessibility text survive |
| Images / vector art | Not re-encoded — passed through as-is | No quality change, no extra shrink from images |
PDF tier limits (this tool uses the PDF family)
Limits enforced before processing starts. The font subsetter accepts PDF input, so PDF-family limits apply — not the standalone font-tool limits.
| Tier | Max file size | Max pages | Batch files |
|---|---|---|---|
| Free | 2 MB | 50 | 1 |
| Pro | 50 MB | 500 | 5 |
| Pro Media | 500 MB | 500 | 5 |
When to reach for a different tool
Font analysis only helps when fonts are the bulk. Pick the tool that matches where your bytes actually are.
| Your file is dominated by… | Best tool | Why |
|---|---|---|
| Large embedded font families, mostly text | PDF Font Subsetter (this tool) | Font-aware re-save + object-stream repack |
| Photos / scans / slide exports | Lossy compression | Re-encodes images to hit a target size |
| Selectable text you must keep, modest bloat | Lossless compression | Object-stream + structure optimisation, no quality loss |
| A file you'll stream to readers online | Linearize | Fast-web-view byte ordering for first-page display |
Cookbook
Real-world before/after scenarios. The tool has no options, so each example is about the input shape and what to expect from the output.
A report with a full Latin font family embedded
A 40-page corporate report embeds Source Sans in four weights, each a full ~80 KB program, but the body uses only Latin letters, digits, and punctuation. The re-save repacks the document with object streams.
Input: report.pdf 3.1 MB (40 pages, 4 embedded weights) Process: Font Subsetter (no options) Output: report.pdf 2.4 MB Result tiles: Input pages: 40 Input size: 3.1 MB Output size: 2.4 MB Processing: Browser
A text-only PDF already tightly packed
An invoice generated by a modern library already uses subsetted fonts and compact streams. There is little to gain — the output is roughly the same size, which is the honest result.
Input: invoice.pdf 88 KB Process: Font Subsetter Output: invoice.pdf 86 KB (≈ no change — already optimal) Takeaway: if the result barely moves, the file was already well-optimised. Nothing is broken.
An image-heavy PDF that won't shrink here
A 12 MB brochure is 95% high-resolution images. Font analysis can't touch images, so the byte reduction is tiny. The right move is a compressor.
Input: brochure.pdf 12 MB (mostly images)
Process: Font Subsetter
Output: brochure.pdf 11.8 MB (only the structure repacked)
Better: run /pdf-tools/pdf-compress-lossy with a target size
→ 1–2 MB by re-encoding the imagesConfirming text still copies after processing
Because ToUnicode maps and content streams are preserved on the round-trip, selectable text survives. Verify by copying a paragraph from the output.
1. Process the PDF 2. Open the output in your reader 3. Select a paragraph → Ctrl/Cmd+C → paste into a text editor → text comes through verbatim, accents intact (If text was already an image in the source, it stays an image — run /pdf-tools/pdf-ocr first to add a text layer.)
Free-tier file just over the 2 MB cap
A 2.3 MB file is rejected on the free tier before processing. Either compress it under 2 MB first or use Pro (50 MB).
Input: manual.pdf 2.3 MB
Free tier limit: 2 MB → rejected before processing
Fix: /pdf-tools/pdf-compress-lossless → 1.7 MB
then /pdf-tools/pdf-font-subsetter
Or: upgrade to Pro (50 MB cap)Edge cases and what actually happens
Output is the same size as the input
By designIf the source already uses subsetted fonts and compact object streams, there is nothing left to remove and the output will be within a few KB of the input. That is the correct, honest result — not a failure. Files produced by modern toolchains (LaTeX, recent Office, headless Chromium) are often already optimal.
Fonts aren't embedded in the source at all
Cannot embedThis tool analyses and re-saves embedded font programs; it does not add a font that was never in the file. If your PDF references a system font without embedding it, this tool cannot fix the resulting missing-font behaviour — the glyph data simply isn't present to subset. There is no in-product 'embed from my system fonts' path.
The bulk of the file is images, not fonts
Use a compressorFont analysis can't shrink JPEG/PNG image XObjects. A scan or photo-heavy PDF will see only the structural repack. Use lossy compression to hit a size target, or lossless compression if you must keep selectable text.
File exceeds the tier size limit
rejectedFree tier rejects PDFs over 2 MB or 50 pages before any processing runs. Pro raises the limit to 50 MB / 500 pages and Pro Media to 500 MB. The check happens up front, so an oversized file never starts processing.
A font program fails to parse
PreservedIf fontkit can't parse a particular embedded program (a corrupt or unusual Type 0/CID structure), that font is left intact and the rest of the document is still re-saved. You never get a broken font as a result of a parse failure — worst case is that one font isn't analysed.
Encrypted / password-protected PDF
SupportedThe document is loaded with encryption ignored for reading, so processing can proceed. If a strongly encrypted file fails to parse, remove the password first with PDF Unlock or Remove Password, then run the subsetter.
Scanned PDF with no real text layer
No fonts to touchA pure scan has no embedded fonts — the page is an image. The tool will repack the structure but find no glyphs to analyse. Add a text layer with PDF OCR first if you want searchable text, then compress the images with the lossy compressor.
Very large multi-page document
slow but worksEach page's text content is parsed in the browser to collect used codepoints, so a 400-page document takes noticeably longer and uses more memory than a short one. It still completes; give the tab a moment. Splitting first with PDF Split can help on huge files.
Frequently asked questions
How much smaller will my PDF get?
It depends entirely on the source. A document that embeds full font families and is otherwise text-heavy can shrink meaningfully on the object-stream re-save; a file already produced with subsetted fonts and compact streams will barely move. Image-dominated PDFs see almost no change here because images aren't touched — use a compressor for those. The result panel shows the exact before/after sizes so you can see the real number.
What options can I configure?
None. The font subsetter is a single-button tool: drop a PDF, press Process, download. There is no quality slider, no per-font selection, and no preset. That keeps the output deterministic — the same input always produces the same result.
Does it change how my text looks?
No. The glyphs that are actually used are preserved, and the page content streams and Unicode maps are kept on the round-trip. Text renders identically and stays selectable and searchable.
Will the text still be searchable and copyable afterwards?
Yes. The tool preserves each font's ToUnicode mapping and the page content, so search and copy/paste keep working. If your source was a scan with no text layer, there was nothing to keep searchable in the first place — run OCR first.
Can it embed a font that isn't embedded in my PDF?
No. This tool analyses and re-saves fonts that are already embedded in the file. If a font was never embedded, the glyph data isn't present to work with, and there is no 'pull from my installed fonts' feature. For documents that reference unembedded system fonts, the fix has to happen in the application that produced the PDF.
Is my file uploaded to a server?
No. Loading, analysis, and re-saving all happen in your browser tab using pdf-lib, pdfjs, and fontkit. The PDF never leaves your device, which is why it is safe for contracts, IDs, and confidential reports.
What's the largest file I can process?
On the free tier, 2 MB and up to 50 pages. Pro raises that to 50 MB and 500 pages, and Pro Media to 500 MB. These are the PDF-family limits, because the tool accepts PDF input. Oversized files are rejected before processing starts.
Why didn't my file get any smaller?
Three common reasons: the source was already optimised (subsetted fonts, packed streams); the bulk of your file is images, which this tool doesn't touch; or the fonts weren't embedded, so there was nothing to analyse. The output size in the result panel tells you which case you're in.
Should I run this before or after compressing?
Run it alongside the right compressor for your bottleneck. For an image-heavy PDF, lossy compression does the heavy lifting; for a text-heavy file with bloated structure, lossless compression and this tool overlap (both repack object streams). Running both is harmless — the second pass simply finds less to do.
Does it work on encrypted PDFs?
It loads documents with encryption ignored for reading, so most password-protected files process fine. If a strongly encrypted file fails to parse, remove the password first with PDF Unlock or Remove Password, then re-run the subsetter.
Will it break my PDF/A or accessibility tagging?
The re-save preserves content streams, Unicode maps, and structure, so text-layer accessibility is retained. If you specifically need a PDF/A-tagged output, use the dedicated PDF to PDF/A tool, which adds the XMP identifier and output intent that archival validators look for.
Can I process several PDFs at once?
Not on the free tier — it's one file per run. Pro allows up to 5 PDFs in a batch. If you have many files, upgrade or process them sequentially.
Privacy first
All PDF processing runs locally in your browser using PDF-lib and pdf.js. No file is ever uploaded — only metadata counters are saved for signed-in dashboard stats.