What Actually Makes PDFs Huge — and Why Local Compression Is the Only Enterprise Answer

Technical notes on document bloat, compliance constraints, and LLM pipeline costs. No product pitch; one personal anecdote at the end.

Why your 20 MB PDF is 20 MB

It's almost never the text. Three usual suspects:

• Full-resolution embedded bitmaps. A 300 DPI A4 scan is ~25 MB of raw bitmap per page; a 100-page scan without compression is gigabytes. PDFs don't lossily compress embedded images by default.
• Full font embedding. CJK fonts can add tens of MB; subsetting typically cuts 90%+.
• Duplicated resources. The same watermark embedded 80 times, once per page.

So effective PDF compression = image resampling + lossy/lossless encoding, font subsetting, and resource dedup. Tools that just slap a zip layer on top barely help — which is also why many online compressors underperform: they only treat the surface.

Why online compression is a non-starter for enterprises

Technically fine, compliance-wise disqualified. Upload a contract, bid document, or patient record to a third-party site and the data has left the intranet — for many organizations that's a hard red line, and even where it isn't, you have no idea when (or whether) the server-side copy is deleted.

The enterprise requirement is therefore fully local processing: files never leave the machine. That constrains the stack — native engines written in systems languages (Rust/C++ territory) handle thousand-page documents in minutes, offline, throughput bounded by disk and CPU.

One regional footnote: OFD, the Chinese official-layout document format, isn't recognized by most Western toolchains. If you process government documents, verify coverage explicitly.

The hidden cost in LLM pipelines: image tokens

The lesson I keep re-learning on RAG projects: with multimodal models, page cost is dominated by image tokens, and it scales with resolution. Two practical optimizations:

1. Compress and resolution-fit before inference. Recognition tasks don't need 300 DPI originals. Fit images to what the model actually needs — we've measured image token costs dropping by roughly 85% after adaptation (GPT-4o billing as the reference).
2. Preserve semantic integrity during compression. Fields that OCR or vision models must read — stamps, signatures, table rules — can't blur out. Tune lossy parameters for "machine will read", not "human will glance".

A selection checklist

If your team is evaluating document compression, check in this order:

Priority	Check	Key question
1	Local processing	Fully offline, no upload step?
2	Format coverage	Dedicated handling for PDF/OFD/scans/Office?
3	Quality validation	Does OCR / model recognition still work post-compression?
4	Throughput	End-to-end time for hundred-page docs
5	Deployment	Single machine, intranet server, or forced cloud?

For context: my current setup is SmartSlim for compression (local engine, OFD coverage — a 443-page OFD document processes end-to-end in about two minutes) and MagiFiler for content-based semantic search over poorly-named historical files. Mentioning them only as context; vendors differ a lot, so validate any candidate against the checklist yourself.

Bottom line

Document compression isn't a one-off "find a website" errand. It sits at the intersection of format internals, compliance boundaries, and model-serving cost. Treat local processing as a hard prerequisite, image resampling and font subsetting as table stakes, and "the machine still needs to read it" as your quality bar — that mental model outlasts any single tool.