How to optimise pdf fonts for faster web delivery
- Step 1Open the PDF Font Subsetter — Go to the PDF Font Subsetter. All processing is local — nothing about your soon-to-be-published document leaves the browser.
- Step 2Drop in the PDF you're about to host — One file per run on the free tier (2 MB / 50 pages); Pro allows 50 MB / 500 pages and 5-file batches for publishing several docs.
- Step 3Press Process — No options to set. The tool scans used codepoints, analyses each embedded font, and re-saves with packed object streams. Compare Output size to Input size in the result tiles.
- Step 4Compress images if they dominate the file — If the PDF is image-heavy (screenshots, photos, slides), the font pass won't move the needle — run lossy compression to hit a target byte budget, or lossless to keep text selectable.
- Step 5Linearize for fast first-page display — This tool does not linearize. After the size pass, run PDF Linearize so the file is byte-ordered for 'fast web view' — the first page renders while the rest streams.
- Step 6Deploy to your web server or CDN — Upload the optimised, linearized PDF. Set sensible cache headers so repeat visitors don't re-download it.
The web-delivery pipeline: which tool does which job
Fast PDF web delivery is several optimisations, not one. This tool covers the font step; the others are separate.
| Goal | Tool | What it does |
|---|---|---|
| Trim embedded-font overhead | PDF Font Subsetter (this tool) | Font analysis + object-stream re-save |
| Shrink image-heavy files to a byte budget | Lossy compression | Re-encodes images to hit a target size |
| Shrink while keeping selectable text | Lossless compression | Object-stream + structure optimisation |
| Fast first-page display while streaming | Linearize | 'Fast web view' byte ordering |
| Strip internal metadata before publishing | Metadata Scrubber | Removes author/producer/dates |
What this tool affects for web delivery
Behaviour on the things that matter when serving a PDF over HTTP.
| Factor | Effect | Detail |
|---|---|---|
| Total download size | Reduced | From object-stream repack + font analysis |
| First-page render speed | Not changed | Linearize separately for fast web view |
| Image weight | Not changed | Use a compressor for image-heavy files |
| Searchable text / accessibility | Preserved | Content streams + ToUnicode kept |
| Metadata in the file | Preserved | Scrub separately before publishing |
PDF tier limits for publishing
Limits checked before processing. Pro suits batch pre-deploy passes.
| Tier | Max file size | Max pages | Batch files |
|---|---|---|---|
| Free | 2 MB | 50 | 1 |
| Pro | 50 MB | 500 | 5 |
| Pro Media | 500 MB | 500 | 5 |
Cookbook
Real pre-publish workflows. Because the tool has no options, the variables are the source file and which other tools you chain.
A whitepaper before hosting on a marketing site
A 20-page whitepaper embeds two full font families but is otherwise text and a few vector charts. Optimise fonts, then linearize.
1. /pdf-tools/pdf-font-subsetter → font + structure re-save 2. /pdf-tools/pdf-linearize → fast web view ordering → smaller download AND first page renders while the rest streams
An image-heavy product brochure
A brochure is 90% photography. The font pass barely helps; the compressor is the real win.
Input: brochure.pdf 14 MB (mostly photos)
Font Subsetter: → ~13.5 MB (only structure repacked)
Better: /pdf-tools/pdf-compress-lossy targetSizeKb 2048
→ ~2 MB, then linearize for the webFull pre-deploy chain for a paywalled report
A confidential report needs to be lean, fast, and stripped of internal metadata before going behind a paywall.
1. /pdf-tools/pdf-font-subsetter → font/structure pass 2. /pdf-tools/pdf-metadata-scrubber → remove author/producer 3. /pdf-tools/pdf-linearize → fast web view → deploy; nothing left the browser at any step
Confirming the hosted PDF stays searchable
A web PDF should keep its text layer for SEO, in-browser search, and accessibility. Verify before deploying.
After processing: open output → Ctrl/Cmd+F → search a phrase → found (ToUnicode preserved) Select text → copy → paste → verbatim Screen-reader text layer intact for accessibility
A file already lean from its generator
A PDF exported by a modern headless-Chromium pipeline is already subsetted and packed. The pass barely changes it — that's fine.
Input: doc.pdf 240 KB (already subsetted, packed) Font Subsetter: → ~235 KB (near no-op) Still worth linearizing for fast first-page display on the web.
Edge cases and what actually happens
You expected this tool to linearize for fast web view
Not linearizedThis tool reduces size; it does not produce a linearized ('fast web view') file. First-page-while-streaming behaviour requires byte reordering — run PDF Linearize after the size pass to get it.
The file is image-heavy, so it barely shrinks
Use a compressorFont analysis can't touch images. A photo- or screenshot-heavy web PDF won't get meaningfully smaller here. Use lossy compression to hit a byte budget, or lossless to preserve selectable text.
Output is about the same size as the input
By designFiles exported by modern generators are often already subsetted and packed. A near-no-op result means the source was already lean — there was simply little structural overhead to remove.
Internal metadata is still embedded before publishing
Scrub separatelyThe re-save preserves document metadata (author, producer, dates). For a public web PDF you may not want that information exposed — run Metadata Scrubber before deploying.
Fonts weren't embedded in the source
Cannot embedIf a web PDF references unembedded fonts, viewers' browsers substitute typefaces and the layout shifts. This tool can't embed a font that isn't in the file — regenerate the PDF from its source with font embedding enabled before publishing.
An embedded font fails to parse
PreservedIf fontkit can't parse one embedded program, that font is left intact and the rest of the document is re-saved. A parse failure never produces a broken web file.
File over the tier size/page limit
rejectedFree rejects PDFs over 2 MB or 50 pages before processing. For larger publish jobs use Pro (50 MB / 500 pages) or Pro Media (500 MB).
Encrypted PDF you're preparing for the web
SupportedThe tool reads with encryption ignored, so most protected files process. If you're publishing publicly, you likely want to remove protection first with Remove Password anyway.
Frequently asked questions
Does this tool linearize my PDF for fast web view?
No. It reduces size via font analysis and an object-stream re-save, but it does not reorder bytes for 'fast web view'. To make the first page render while the rest streams, run PDF Linearize as a separate step after this one. The two together give you both smaller downloads and faster first-page display.
How much faster will my hosted PDF load?
It depends on what was bloating the file. If fonts were the overhead, the smaller download helps directly. If images dominate, the font pass barely helps and you'll want a compressor. The biggest perceived-speed win on the web usually comes from linearization plus image compression, with font optimisation contributing to total bytes.
Will it reduce my CDN bandwidth bill?
If embedded fonts are a meaningful share of the file, yes — a smaller PDF means less egress on every download, which adds up on high-traffic document portals. The result panel shows the exact per-file reduction so you can estimate the saving across your traffic.
Does the optimised PDF stay searchable and accessible?
Yes. Content streams and ToUnicode maps are preserved, so the text layer survives — important for in-browser search, SEO of the document text, and screen-reader accessibility on a public site.
Should I also compress the PDF for web delivery?
If it's image-heavy, absolutely — run lossy compression to hit a byte budget (or lossless to keep text selectable). For a text-heavy file, this tool and lossless compression overlap (both repack object streams), so one pass may be enough. Then linearize.
What's the right order: subset, compress, linearize?
A practical web pipeline is: optimise fonts here, compress images with the appropriate compressor, then linearize last so the byte ordering for fast web view isn't disturbed by a later re-save. Scrub metadata anywhere before deploy.
Will it work on variable fonts?
Variable fonts are handled through the same embedded-font analysis path — the tool works with whatever font programs are present in the PDF. As with any font here, it optimises what's embedded; it doesn't add or re-instance fonts that aren't in the file.
Does font optimisation hurt accessibility tags?
No. The re-save preserves the text content and Unicode mapping, so the accessible text layer is retained. Structural tags carried in the document are passed through on the round-trip.
Is my pre-publication document uploaded anywhere?
No. pdf-lib, pdfjs, and fontkit all run in your browser tab and the file never leaves your device — safe for paywalled, embargoed, or client-confidential documents before they go live.
What if my web PDF references fonts that aren't embedded?
Then visitors' browsers substitute their own fonts and the layout shifts unpredictably. This tool can't embed a missing font. Regenerate the PDF from its source application with font embedding enabled before publishing, then optimise it here.
Can I batch-optimise a set of documents before deploy?
On the free tier it's one file per run. Pro allows 5 PDFs per batch. For a publish queue of many files, Pro or Pro Media is the practical tier; otherwise process them sequentially.
What's the largest PDF I can optimise for the web?
Free is 2 MB / 50 pages, Pro is 50 MB / 500 pages, and Pro Media is 500 MB. These are the PDF-family limits. Files over the cap are rejected before processing, so check your file size against your tier first.
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.