How to Compress PDF Files Without Losing Quality

A PDF is not a single blob of content — it is a structured container of objects: page trees, font programs, colour profiles, metadata dictionaries, and the streams that hold the actual page content. Every one of those objects carries structural overhead: headers, cross-reference entries, dictionary keys, and length declarations. A text-heavy PDF exported from a word processor can contain hundreds of small objects, each padded with the syntax the format requires to stay randomly accessible. That overhead is invisible on screen but it all counts toward the file size.

The other major contributor is embedded imagery. A scanned document is essentially a stack of full-page images, and a scanner set to 300 dpi on A4 produces roughly 8.7 million pixels per page. Stored uncompressed, that is tens of megabytes per page; even with the JPEG encoding most scanners apply, scans dominate the size of any document they appear in. Photographs inside a report, charts exported as images rather than vectors, and screenshots pasted at full resolution all add the same kind of weight.

Fonts are the third common culprit. Embedding a full font program guarantees the document looks identical everywhere, but a complete font family can add hundreds of kilobytes. Professional pre-press tools subset fonts — embedding only the glyphs actually used — but everyday exporters often embed more than is needed. Understanding which of these three sources dominates your file is the first step, because each one responds to a different remedy. You can usually tell by opening the PDF and trying to select text: if you can highlight words, the file has a real text layer; if you cannot, you are looking at images.

There are two distinct families of PDF compression, and confusing them is the most common reason people are disappointed by the result. The first family is structural optimisation: re-saving the document so its objects are packed more efficiently. The second family is content re-encoding: actually re-compressing the images and streams inside the document, usually with lossy quality trade-offs.

Structural optimisation works by consolidating the many small objects a PDF contains into compressed object streams. Instead of every object sitting alone in the file with its own header and cross-reference entry, groups of objects are bundled into a single stream and compressed together with the DEFLATE algorithm — the same family of compression behind ZIP and gzip. The reader then unpacks that stream on open. Because the page content itself is untouched, this is lossless: every glyph, vector, and pixel comes out exactly as it went in. The trade-off is that the savings are bounded by how much structural overhead the file had in the first place.

Content re-encoding is where quality trade-offs live. Re-compressing an embedded image at a lower JPEG quality, downsampling it to a lower resolution, or converting a colour scan to grayscale can cut a file dramatically — but each of those decisions discards information. There is no free lunch: a 4 MB scan becomes a 400 KB scan by throwing away pixel data, and at some setting the artefacts become visible.

This is the single most common surprise. If your PDF is a scan, almost all of its bytes are inside one or two large, already-compressed image streams per page. Structural overhead might be 2–5% of the file. Re-packing the objects therefore saves 2–5% — a rounding error, not a fix. The scan was already JPEG-compressed at the scanner, so there is very little redundancy left for object-stream packing to remove.

The honest remedy for scan-heavy documents is to rasterise and re-encode: render each page to an image at a chosen resolution, then rebuild the PDF from those images at a JPEG quality you pick. That is a genuinely lossy operation — the text on the page stops being selectable and searchable, because it is now pixels rather than glyph instructions — but for a scan that was never searchable to begin with, you lose nothing you had. A 300 dpi grayscale re-encode at quality 75 routinely turns a scanner's bloated output into a fraction of its size with no visible degradation for reading on screen.

A useful rule of thumb: if the PDF came from a scanner, plan on image-level re-encoding. If it came from a word processor, export, or report generator, structural compression and font subsetting are where the wins are. The PDF Compressor on this site runs the lossless structural path in your browser, so it is best suited to text-heavy and export-generated files; for scan-heavy files, use the PDF to Image tool to rasterise pages, then rebuild with Image to PDF.

DPI (dots per inch) describes how many pixels a rasterised page carries per inch of paper. A 72 dpi render is fine for quick screen previewing but looks soft when printed. 144 dpi is comfortable for on-screen reading and modest file sizes. 216–300 dpi is the print-quality range, and file size scales roughly with the square of the dpi — doubling the resolution quadruples the pixel count.

When you rasterise a page, you are making a deliberate exchange: you give up the text layer (selection, search, copy-paste, and accessibility for screen readers) in return for full control over the image encoding. That is the right trade when the source is a scan or when the document is going to be viewed as a fixed picture, and the wrong trade when anyone downstream needs to search or extract the text. If you need both small size and searchable text, the professional answer is OCR — running optical character recognition so a text layer is added back on top of the images — which browser-based tools do not perform.

The quality dial matters as much as the resolution. JPEG quality around 90–95 is visually indistinguishable from the original for most documents; 70–80 is the sweet spot where artefacts are still essentially invisible on text and line art but the size savings are substantial; below about 60, ringing artefacts start to appear around sharp edges — exactly where documents have their contrast. For black-and-white text documents, converting to grayscale before encoding often saves another 20–30% with zero perceptual cost, because the colour channels were carrying nothing but scanner noise.

Start by running structural compression first — it is lossless, so there is no reason not to. Open the PDF Compressor, load your file, and download the result. Check the size: if it is acceptable, you are done and nothing about the document changed visually.

If the file is scan-heavy, take the rasterise-and-re-encode path. Render the pages with PDF to Image at a resolution matched to the use: 144 dpi for on-screen sharing, 216 dpi if it may be printed. Encode at quality 75–80, grayscale if the content is black-and-white. Then rebuild with Image to PDF and sanity-check a couple of pages at full zoom for artefacts before you distribute the result. Keep the original — compression decisions are one-way doors, and you want the option to revisit them.

If the document is simply too large for an email system even after compression, splitting is often the better answer than degrading quality. Most mail providers cap attachments somewhere between 10 and 25 MB. Sending two clean halves at full quality is usually better received than one muddy file that squeezes under the limit. Use the PDF Splitter for that.

Consider three real-shaped files and how the diagnosis changes the remedy. The first is a 1.2 MB quarterly report exported from a word processor — mostly text, a handful of vector charts, subset fonts. Structural compression re-packs its objects and lands at roughly 0.9 MB, a 25% reduction with zero quality loss, because the file was carrying meaningful overhead from its many small objects. Re-encoding its images would gain almost nothing, because there are almost no images.

The second is an 18 MB scanned contract — full-page JPEG images, no text layer. Structural compression barely moves the needle, landing at 17 MB, because the bytes are inside two already-compressed image streams per page. The honest fix is to rasterise and re-encode: render at 150 dpi, grayscale, quality 78, which rebuilds the file at roughly 2.4 MB. You lose nothing you had (the scan was never searchable) and gain a 7x reduction.

The third is a 6 MB marketing brochure with embedded product photography. Structural compression takes it to 5.4 MB. The photographs dominate, so the further win lives in re-encoding them — but here you must decide whether the document needs to remain press-quality. If it is destined for screen sharing, downsampling the photos to 150 dpi and quality 80 reaches roughly 1.8 MB with no visible loss on screen; if it is going to a commercial printer, leave the images alone and accept the size. The decision framework is: diagnose the dominant byte source, choose the remedy that touches that source, and stop when the file serves its readers.

Some files are already optimal. A PDF that was produced by a modern exporter with object streams enabled, subset fonts, and sensibly encoded images has little left to give; re-compressing it yields single-digit percentages. Similarly, a PDF that is encrypted or protected by an owner password that blocks copying cannot be processed at all until that restriction is removed in the originating application.

It is also worth being sceptical of any tool promising "90% smaller with no quality loss" on arbitrary input. Lossless structural compression is bounded by the overhead present; large lossy reductions always come from discarding image data. A trustworthy tool tells you which of the two it is doing and lets you see the trade-off. The goal is not the smallest possible file — it is the smallest file that still serves its readers, prints cleanly, and keeps the text accessible when accessibility matters.