How to Compress a PDF Without Losing Quality: What Actually Works

People are usually surprised to learn that the text in their document is not the problem. Text in a PDF is stored as font glyphs placed at coordinates, plus the embedded font program itself. A 100-page report of pure text is typically a few hundred kilobytes, and compressing it further yields almost nothing because the content streams are already Flate-compressed.

The size comes from images. Three situations dominate. First, scanned documents: every page is a photograph of a page, often captured at 300 dots per inch in colour, which is several megabytes per page before any compression. Second, documents assembled from screenshots or exported from design software, where each screen capture is embedded at full resolution. Third, presentations exported to PDF, where a handful of full-page images account for nearly the entire file.

There is a second, smaller category: waste. A PDF may carry unused objects, an obsolete cross-reference section, a large embedded colour profile, or a full font program when only a dozen glyphs are used. This is where lossless optimisation earns its keep, and it is usually worth somewhere between a few percent and perhaps a third of the file, depending on how well the original was built.

The diagnostic question is therefore always the same: is this file large because of images, or because of waste? The answer determines which of the two very different techniques will help.

Lossless optimisation changes how the file is stored without changing what it renders. Nothing is discarded that affects appearance, so the output is visually identical to the input, and text remains selectable and searchable.

The main techniques are straightforward. Content streams are recompressed with Flate, which is the same Deflate algorithm used in ZIP archives and is already the standard compression method in PDF. Objects are gathered into compressed object streams so that the cross-reference table itself no longer needs to be stored as plain text. Unreferenced objects left behind by earlier editing are dropped. Document metadata such as the producing application, author, and revision history can be cleared, which saves a little space and, incidentally, removes information you may not want to distribute.

What lossless optimisation cannot do is reduce the size of image data. A 4-megapixel scan is a 4-megapixel scan. If images dominate the file, lossless techniques will produce a disappointing result, and that is not a failure of the tool. It is the correct outcome of applying a lossless method to data that needs a lossy one.

The value of lossless optimisation is that it is always safe. There is no quality decision to make and no risk of degrading a document you may later need to print or archive.

If a document is large because of images, the only meaningful lever is to store fewer pixels or store them less precisely. Both are lossy, and both are frequently the right decision.

Downsampling reduces the pixel dimensions of an image. A scan captured at 600 dots per inch contains four times the pixels of the same page at 300, and sixteen times that of 150. Since screen display rarely needs more than about 150 pixels per inch of page, and ordinary desktop printing is well served by 200 to 300, a scan intended for reading on screen or printing on an office printer has a great deal of redundant detail.

Re-encoding changes how those pixels are compressed. Photographic and scanned content compresses well with JPEG at a moderate quality setting, and the visible difference between quality 90 and quality 75 is usually negligible on a scanned page of text, while the size difference is substantial. Line art and screenshots compress better with other methods and can degrade badly under JPEG, producing visible fringing around sharp edges.

Colour reduction is the third lever and is often overlooked. A colour scan of a black-and-white document wastes two thirds of its data. Converting to greyscale, or to a bitonal representation for genuinely black-and-white pages, can produce very large reductions with no loss of legibility.

The reason to be careful here is that these operations are irreversible in the output file. Once a page has been downsampled and re-encoded, the discarded detail is gone. Keep the original, and treat the compressed version as a distribution copy.

It is worth being precise here, because compression is the operation where online tools most often overstate their results.

Rewriting a PDF with compressed object streams and stripped metadata is a structural operation, and a browser handles it easily. This is genuine lossless optimisation, it runs instantly, and it is the correct tool for removing waste from a file.

Re-encoding hundreds of embedded images is a much heavier operation. It requires decoding each image, resampling it, re-encoding it, and rebuilding the page resources that reference it. Doing this for a 200-page scan in JavaScript inside a browser tab is possible but slow and memory-intensive, and it is the kind of work where a desktop application or a server-side pipeline currently has a genuine advantage.

So the honest position is this: a browser compressor is excellent at lossless optimisation and should be expected to deliver modest savings on well-built files and larger savings on files that were assembled carelessly. It is not the tool to reach for when you need to turn a 120 MB colour scan into a 4 MB email attachment. For that job, look for a tool that explicitly performs image downsampling, and check the output quality yourself before you send it.

Compression settings should follow the destination of the file, not a preference for the smallest possible number.

The workflow is short. The important part is checking the result rather than trusting the summary.

There are situations where compression is the wrong move, and recognising them saves you a support ticket later.

Do not compress a document that is already optimised and whose size is acceptable. Applying lossless optimisation to an already-optimised file typically saves nothing, and a tool that reports a reduction in that situation is worth treating with suspicion.

Do not compress the only copy of anything. Compression produces a new file, and lossy compression is irreversible. Keep the original until the compressed version has been accepted.

Do not compress before signing. Any later modification invalidates a digital signature, so the correct order is to finalise the content, compress, and then sign the result. The signing guide covers what a signature actually covers and why this ordering matters.

Do not compress a document whose evidential value depends on its exact bytes. In regulated contexts, the artefact that was submitted is the artefact that matters, and a re-saved version is a different file.