Feb 12, 2026 · 13 min read · Optimize

The Science of PDF Compression

Almost every professional has lived this scene: you finish a quarterly report, hit "Save as PDF," and watch the file weigh in at 78 MB. Outlook rejects it. SharePoint rejects it. Your client portal rejects it. So you scramble for a "PDF compressor," paste your document into the first result on Google, and pray that the unknown service on the other end actually deletes the upload after processing.

There is a much better path. Compression is not magic, it is a small set of well-understood transformations on the byte structure of the PDF, and once you understand the four levers, you can choose the right tradeoff every time. This guide walks through how PDFs get bloated, how compression actually works, and how to use pdfwithlove's Compress PDF tool effectively for the three document types that cause the most trouble.

Why a 12-page report ends up at 78 MB

A PDF is a container format that can hold text, raster images, vector graphics, embedded fonts, color profiles, metadata, and even attached files. Every one of those pieces is a candidate for inefficiency:

Images saved at print resolution. A photo captured on a modern phone is roughly 4000 by 3000 pixels. If your report embeds that photo at 4 inches wide, the PDF is storing about 1000 pixels per inch when 150 is plenty for screen viewing.
Lossless image encodings. Screenshots saved as PNG inside a PDF stay PNG. PNG is lossless, which is great for crispness and terrible for size.
Full font embedding. Embedding the entire Helvetica family adds about 2 MB of glyph data. If your document only uses Helvetica Regular and Bold, the rest is dead weight.
Multiple color profiles. Some Office exporters bundle two or three ICC color profiles into the file even when only one is referenced.
Revision artifacts. Word's PDF export sometimes carries forward old object versions, comments, and tracked changes as hidden objects.
Uncompressed object streams. PDFs allow most internal objects to be wrapped in a Flate (zlib) stream. Cheap exporters skip that step.

A 78 MB report on a 12-page outline almost always boils down to one of these: oversized embedded images and unsubsetted fonts.

The four levers of PDF compression

Every serious PDF compressor pulls some combination of these four levers. Understanding them is the difference between blindly clicking "compress" and choosing the right preset for the job.

Lever 1: Image downsampling

This is the heaviest hitter, often responsible for 70 to 90 percent of the size reduction in a typical document. The compressor inspects every embedded image, asks how big it actually appears on the page, and resamples it to a target DPI.

The math is straightforward: a 300 DPI image displayed at 4 inches wide is 1200 pixels of raw data. The same visual at 150 DPI is 600 pixels, which is one quarter of the original byte count. For documents that will be read on screens, 150 DPI is essentially indistinguishable from 300 DPI. For documents that will be printed at production-grade quality, 300 DPI is the floor.

pdfwithlove preset mapping:

High quality (recommended for screens): 150 DPI for color and grayscale images, 300 DPI for line art.
Medium quality: 96 DPI for color and grayscale, 200 DPI for line art. Good for email-sized files.
Low quality: 72 DPI for color and grayscale, 150 DPI for line art. Use only for archival reference where readability matters more than visual fidelity.

Lever 2: Image re-encoding

Once you have the right number of pixels, you still have to choose the right encoding. The rules of thumb that have not changed in twenty years still apply:

Photographs: JPEG at quality 75 to 85 is the sweet spot. JPEG quality 100 is essentially uncompressed and roughly twice the size of quality 85 with no perceptual difference for most viewers.
Screenshots, charts, line drawings: Keep PNG or convert to a low-quality JPEG only if you accept some halo artifacts around sharp edges.
Black-and-white scans: CCITT Group 4 (the fax encoding) is dramatically more efficient than JPEG and lossless for bilevel content.

A modern PDF compressor inspects each image independently and chooses the right encoding rather than applying a blanket rule. That is why a 50 MB document of mixed scans and screenshots can compress to 4 MB without any visible quality loss.

Lever 3: Font subsetting

Every embedded font dictionary in a PDF can be either fully embedded (every glyph in the font) or subsetted (only the glyphs actually used). Subsetting is the standard for production PDFs, but plenty of exporters skip it. A document that uses three fonts and embeds them in full might carry 6 MB of font data; the same document with subsetting carries about 200 KB.

Subsetting is lossless from a viewing perspective: every character that appears in the document still renders perfectly. The only catch is that you cannot edit the document later and type new characters that were not in the original, because their glyphs are no longer in the file. For finalized documents (anything you are about to send), this is a free win.

Lever 4: Object stream compression and cleanup

PDFs have a lot of small internal bookkeeping objects: cross-reference entries, page tree nodes, font dictionaries, annotation lists. Each of these can be wrapped in a Flate-compressed object stream, which both reduces their size and reduces the number of separate xref entries. A "linearized" PDF takes this further by reorganizing the byte layout so the first page can render before the entire file is downloaded.

This lever rarely produces dramatic savings on its own (typically 5 to 15 percent), but it is essentially free: there is no quality tradeoff, no risk to the visual fidelity of the document. Modern compressors apply it automatically.

A separate cleanup pass can also remove:

Unreferenced objects left behind by editing software.
Embedded thumbnails (which most viewers regenerate on demand anyway).
Document-level JavaScript and form actions that you do not actually need.
Multiple redundant ICC color profiles.

Walkthrough: Choosing a preset for three real document types

The right preset depends entirely on what is in the document and where it is going. Here is how to think about three common cases.

Case 1: A 14 MB sales proposal headed for client email

This is the canonical use case. The document is mostly text with a handful of product photos and a cover image, and it needs to fit comfortably under a 10 MB email cap.

Preset: High quality (150 DPI).
Expected result: 2 to 4 MB output.
Why it works: The product photos drop from print resolution to screen resolution, JPEG quality settles in the high-80s, and font subsetting handles the rest. The client cannot see any difference.

Case 2: A 240 MB scanned legal binder

Scanned documents are nearly always image-only PDFs, where each page is a single big raster. Compression here is mostly about choosing the right encoding for the scan type.

Preset: High quality (150 DPI), with the OCR option enabled if the binder is not yet searchable.
Expected result: 30 to 60 MB output, fully searchable.
Why it works: Color scans get JPEG re-encoding, black-and-white pages get CCITT Group 4, and the OCR pass adds a hidden text layer so the file becomes searchable without any visual change.

If the binder absolutely must fit under 25 MB for an electronic court filing, drop to medium quality (96 DPI). Read a few pages at 100 percent zoom before sending to confirm small text is still legible.

Case 3: A 180 MB graphics-heavy report with charts and infographics

This is the case where naive compression goes wrong. Charts and infographics are mostly vector graphics inside the PDF, and downsampling does not apply to them. The damage usually comes from a few embedded raster images (cover photo, contributor headshots, a screenshot or two).

Preset: High quality, never lower.
Expected result: 60 to 100 MB output.
Why it works: Vector graphics are already efficient and compress trivially with object stream compression. The savings come almost entirely from the few embedded rasters and from font subsetting.
Why not medium or low: Aggressive image compression can introduce JPEG artifacts in the cover photo or visible banding in gradient backgrounds, which destroys the polish of an otherwise pristine report.

If the report is still too large, the right move is not more compression: it is to find the one or two oversized images that are skewing the total. Most PDF inspectors can list embedded objects by size, and replacing a single 40 MB raster with a 2 MB version often does more than any preset change.

What compression cannot fix

A few problems masquerade as compression problems but really are not:

A PDF made of full-page screenshots of text. The right fix is OCR plus rebuild, not compression. A text-based PDF is roughly 1 percent the size of an image-based one with the same content.
A PDF that has been "merged then re-saved" three times. Each save can leave behind orphan objects. Run it through compression once with the cleanup pass enabled, and stop re-saving.
A PDF that legitimately contains 500 high-resolution photos. No amount of byte-level compression makes 500 photos small. Either reduce the number of photos, the resolution, or accept the size.

Why local matters here too

Compression touches every byte in the document. Every byte. If the file contains anything sensitive, every byte travels to whatever cloud service you used and sits in their processing pipeline at least temporarily. Even reputable services have had incidents where temporary processing buckets were accidentally indexed by search engines.

Browser-based compression has none of that exposure. Your file is parsed, transformed, and re-encoded entirely within the tab you have open. Closing the tab is the equivalent of shredding the whole pipeline.

For a public marketing flyer, none of this matters. For an unannounced earnings report, a redacted court filing, or a patient summary, it is the only acceptable approach.

A practical compression checklist

Before you send any PDF over 5 MB, run through this checklist:

Is it text-heavy with a few images? High quality preset. Done.
Is it a scanned binder? High quality with OCR. Done.
Is it graphics-heavy and still too large? Find the oversized images individually. Compression presets cannot save you.
Did the file pass through a clunky exporter (Office, a legacy reporting tool, a third-party converter)? Always run a single compression pass with cleanup enabled, even at high quality. The cleanup alone often shaves 20 to 40 percent.
Is the file destined for archival or regulated submission? Use PDF to PDF/A rather than generic compression so you keep the long-term readability guarantees.

Compression is one of the few document operations where the right defaults take you 90 percent of the way there. Understand the levers, choose the preset that matches your document type, and stop sending 78 MB attachments to people who will never open them.