How PDF Compression Actually Works: Images, Fonts, Metadata, and File Size

A PDF can be surprisingly large even when it contains only a few pages. Scanned pages, photographs, embedded fonts, and other resources can contribute more to file size than the visible text suggests. Understanding what is actually inside the file is the difference between compressing effectively and wondering why nothing shrank.

The short version

PDF size comes almost entirely from the resources embedded in the document — raster images first, then embedded fonts and duplicated objects — not from the text itself. Compression removes or re-encodes those resources, and the result depends heavily on what the source document contains.

Container size versus content

A PDF is a container. It holds text, vector shapes, images, fonts, metadata, and the internal objects that describe how pages are structured. The container itself is cheap. The content is where the bytes live, and the mix of content varies wildly between documents.

This is why a 10-page text PDF can be smaller than a 3-page scanned one. The text PDF stores only selectable characters and font outlines; the scan stores three full-page images. Content, not page count, decides file size.

What actually consumes bytes

• Raster images — photographs, scans, and screenshots dominate. A single full-page 300 DPI scan can weigh several megabytes on its own.
• Embedded fonts — fonts embedded whole (rather than subset to the characters used) add hundreds of kilobytes per font.
• Duplicate resources — the same logo or image repeated across pages is often stored once but can be duplicated when documents are assembled from other documents.
• Metadata and edit history — author fields, timestamps, and preview data from office suites. Usually a small share of the total, but present in almost every file.
• Object streams — the internal structure that stores objects; how efficiently it is packed affects the final size at the margins.

How compression generally works

PDF compression operates on these resources in a few standard ways:

• Image recompression — re-encoding images at lower quality or resolution. This is lossy: the file shrinks because visual detail is discarded. This is where most real-world PDF savings come from, and it is why scanned documents are the best candidates.
• Font subsetting — keeping only the glyphs actually used instead of the whole font.
• Deduplication — merging repeated objects so each is stored once.
• Re-serialization — rewriting the document structure more efficiently, often using compressed object streams.

Lossless versus lossy

The two approaches trade file size against fidelity:

• Lossless — the document's information is preserved exactly. Text, layout, and images come out identical; savings come from packing structure more efficiently, which is modest.
• Lossy — some information is discarded, usually image quality. The file can shrink dramatically, but you are accepting a visual trade-off that you should verify by looking at the result.

A compressor that only re-serializes is lossless by nature. A compressor that re-encodes images is lossy. Knowing which one you are using tells you how much reduction to expect.

What ToolKitHub's compressor actually does

ToolKitHub's PDF Compressor re-serializes your PDF in the browser — it rebuilds the document structure with optimized object streams and reports whether the output is smaller than the original. It does not re-encode your images, strip metadata, or subset fonts, and it only offers the download when the result actually saved space.

What this means in practice:

• Text-heavy PDFs can benefit the most from structural optimization, but the amount of reduction varies considerably between files — some shrink noticeably, others barely move.
• Scanned documents will barely shrink, because the page images are untouched. They are essentially large JPEGs wrapped in a PDF container.
• Already-optimized PDFs (exported by modern tools) may show little or no change — and that is the honest, correct outcome.

If your goal is a large reduction for an image-heavy file, the compressor is the wrong first step: resize or recompress the embedded images first, then re-save. See the Image Resizer for scaling and the image compression guide for quality settings.

Why some PDFs barely shrink

The most common reason a compressor reports little gain is that the file was already optimized. Modern office suites and PDF tools export reasonably tight files. Another reason is content type: vector-only documents and form-heavy PDFs have little redundancy to remove. If a PDF is under a few hundred kilobytes and contains only text and vector shapes, compression was never going to help much.

How to evaluate the result

1. Compare the before and after sizes the tool reports — ToolKitHub shows both and only offers the smaller file.
2. Open the compressed PDF and check the text on the most image-heavy pages for blur or artifacts.
3. Verify that links, form fields, and annotations still work if the document uses them.
4. Keep the original file when document fidelity matters more than size.

When not to compress

Skip compression for forms that must preserve embedded fields, documents that rely on precise fonts, and anything already under a few hundred kilobytes. Compression adds risk without benefit in those cases.

Try it yourself

Use the PDF Compressor to compare your original and compressed document. Because processing happens in your browser, you can test any file — including contracts and financial records — without uploading it anywhere. For related workflows, see PDF vs DOCX and the guide to merging PDFs.