How PDF Compression Actually Works

A PDF is a container format. Inside it are objects: page descriptions, fonts, images, embedded files, metadata, and instructions for drawing vector graphics and placing text. Compressing a PDF means making those objects smaller, or removing ones nothing refers to.

Understanding which object type dominates your file tells you immediately how much you can expect to save.

Where the bytes actually are

Content	Typical size per page
Plain text	2 to 10 KB
Text with embedded fonts	+50 to 500 KB once per document
Vector diagrams	10 to 100 KB
One photograph	200 KB to 5 MB
Full-page 300 DPI colour scan	1 to 8 MB
Full-page 600 DPI colour scan	4 to 30 MB

The ratio is stark. A single photograph can outweigh two hundred pages of text. This is why "compress PDF" produces such wildly different results on different documents. It is almost entirely a question of whether there are images to work on.

The lossless operations

These change nothing visible and should always run first.

Object stream compression

PDF supports FlateDecode (the same DEFLATE algorithm as ZIP) on content streams. Well-produced PDFs already use it. Files exported by older tools, or generated programmatically without care, sometimes store page content uncompressed, and compressing it can cut the file substantially at zero quality cost.

Removing orphaned objects

PDFs are edited incrementally: changes append to the file rather than rewriting it. Delete a page in some editors and the objects remain, merely unreferenced. A file that has been through several rounds of editing can carry a surprising amount of this. Rewriting the document cleanly (sometimes called linearising or garbage-collecting) discards it.

Font subsetting

A full font file carries thousands of glyphs. If a document uses 62 characters of a typeface, embedding all of it wastes hundreds of kilobytes. Subsetting keeps only the glyphs actually used. Most modern generators do this; many older ones do not, and files assembled by merging several sources often carry several near-identical full fonts.

Deduplication

A logo on every page can be stored once and referenced 200 times, or stored 200 times. Merged documents are especially prone to carrying duplicates of identical resources.

The lossy operations

This is where the large savings are, and where quality goes.

Downsampling

Images inside a PDF have a native resolution, and it is frequently far higher than the page needs. The relevant number is effective DPI:

A 3000px-wide image placed across 6 inches is 500 DPI. Downsampling it to 150 DPI for screen use means 900px, one ninth of the pixels, and roughly one ninth of the bytes before any other compression.

Sensible targets:

Purpose	Target DPI
Screen viewing / email	96 to 150
Office printing	200 to 300
Commercial print	300 to 600
Archival scanning	600+

The commonest mistake is keeping 600 DPI scans for documents that will only ever be read on a screen. That is 16 times the pixel data a 150 DPI screen view requires.

Re-encoding images

Photographs stored as lossless images inside the PDF can be re-encoded as JPEG. Photographs already stored as JPEG can be re-encoded at a lower quality. The second case is generation loss (re-quantising an already-quantised image), so it degrades faster than the quality number suggests.

Colour reduction

A scan of black text on white paper does not need 24-bit colour. Converting to greyscale removes two thirds of the data; converting to 1-bit bitonal removes far more, and for clean text scans it often looks better because it eliminates paper texture and scanner noise. This is what the CCITT Group 4 and JBIG2 encodings are for, and they are dramatically effective on text scans.

A worked case

A 24-page scanned contract, 600 DPI colour, arriving at 47 MB:

1. Downsample to 200 DPI: pixel count falls to about 11% → roughly 5.2 MB
2. Convert to greyscale: a third of the channels → roughly 1.7 MB
3. JPEG quality 75: → roughly 900 KB

A 98% reduction, and the result is still perfectly readable on screen and printable on an office printer. The same three steps applied to a 47 MB text-heavy report with a few charts might save 5%.

What not to do

Do not compress the archival copy. Downsampling is irreversible. Keep the original and distribute the compressed version.

Do not compress a document destined for print. 150 DPI looks fine on a screen and visibly soft on paper.

Do not assume compression removes sensitive content. It does not. Metadata, annotations, form field values, and content hidden underneath a black rectangle all survive. Redaction is a separate operation that removes the underlying objects. Drawing a box over text hides nothing, and this has caused real leaks in published court filings and government documents.

Do not run confidential documents through an upload-based service without reading what it does with them. Many keep files for hours and are perfectly clear about it in terms nobody reads. The compress PDF tool here runs in the browser, which sidesteps the question entirely. See why browser-based tools are different.

Producing smaller PDFs in the first place

• Scan at 300 DPI, not 600, unless you are archiving.
• Scan text in greyscale or bitonal, not colour.
• Insert images already sized for their placement rather than relying on the editor to scale them: most embed the full original.
• Use "Export as PDF" rather than "Print to PDF" where the application offers it. Print paths often rasterise vector content, turning crisp text into an image.
• Run OCR on scans. It adds a searchable text layer, and some pipelines can then discard or heavily compress the image layer.