How to compress a PDF without losing quality

The portal's upload form caps out at 10 MB, your scanned application pack runs to 34 MB, and the submit button stays stubbornly greyed out. It is the most common situation of all: a PDF that reads perfectly well but is far too heavy for the channel it has to pass through. In the vast majority of cases that weight comes from one identifiable cause, and you can cut it by a factor of five or ten without the recipient noticing the slightest difference.

Before compressing, work out where the weight is

A PDF is not an image format, it is a container. It can hold vector text, fonts, bitmap images, form fields, layers and file attachments. The weight is spread very unevenly across all of that.

• Vector text weighs almost nothing. A 40-page report produced in a word processor, with no illustrations, often comes in under 500 KB. There is nothing to be gained there.
• Bitmap images account for the bulk of the volume. An A4 page scanned in colour at 300 dots per inch is 2,480 × 3,508 pixels, or roughly 26 MB of raw data before compression. That is where all the savings are.
• Embedded fonts add anything from 50 KB to several megabytes when the document carries complete character sets — typically CJK fonts, or families with a great many weights.
• Invisible leftovers: page thumbnails, earlier states kept by incremental saves, objects left orphaned, bloated blocks of XMP metadata.

The diagnosis comes down to a single division: file size divided by page count. Under 100 KB a page, the document is already clean and you will shave off only a few per cent. Between 500 KB and 2 MB a page, it contains images or a scan and there is considerable headroom. Above 5 MB a page, it is almost certainly a document photographed on a phone.

The three real levers, and what “lossless” actually means

A word about terminology saves a lot of disappointment: “without losing quality” does not mean the output file is identical to the original down to the bit. It means the degradation stays invisible for the intended use. A document read on screen and the same document destined for an offset press do not have the same requirements, and it is that destination which dictates every setting.

Downsampling the images

This is by far the most powerful lever. Taking an image from 300 to 150 DPI divides its pixel count by four. A photo dropped into a report, displayed 5 cm wide but stored at 4,000 pixels across, is pure waste: very few screens will ever show more than 600 to 900 of them. An office laser printer is perfectly happy with 200 DPI; on-screen reading, with 120 to 150.

JPEG recompression

The sweet spot sits somewhere around 70 to 80 on a scale of 100. Below 50, artefacts show up first on sharp edges — fine text, table rules, chart lines — where they form telltale grey halos. And one rule matters even more than the number you settle on: never recompress a file that has already been compressed. Recompressing at a lower quality than the source stacks fresh artefacts on top of the old ones; re-saving at the same quality as the original degrades it only slightly, but saves practically no bytes at all — you lose quality for nothing. Always start from the original.

Structural clean-up

This one genuinely is lossless: subsetting fonts down to the characters actually used, de-duplicating identical images (a logo repeated across 40 pages only needs storing once), stripping unused objects, recompressing the internal streams. On an ordinary office document, that clean-up alone often removes 10 to 30 per cent of the weight without touching a single pixel.

Which setting for which destination

These figures are orders of magnitude, not hard thresholds: a scan of black text on white paper drops far lower than a brochure full of photographs. The compress a PDF tool applies these trade-offs automatically ; the largest file it will take is shown under the drop zone, on the tool page itself. Processing happens on the server — an 80 MB PDF is well beyond what a browser can handle comfortably — and the file you upload is deleted after an hour.

The special case of scanned documents

This is by far the biggest source of unnecessary weight, and the worst handled. A few habits change everything:

• Scan in greyscale if the document is black text on white paper. That divides the volume by about three, for a result that is indistinguishable when read.
• Avoid photographing pages on a phone when a scanner, or the phone's own document-scanning app, is available. A raw photo keeps the sensor noise, which JPEG handles very badly: noise is random detail, and random detail is expensive in bytes.
• Crop before you compress. The expanse of desk captured around the sheet weighs as much as the text itself.

One thing people often discover too late: compressing a scan does not make it searchable. The text is an image, and it stays an image. If you need to pull the content back out afterwards, check first that your PDF has a genuine text layer — simply try selecting a word in your reader. If nothing selects, no conversion to an editable format will produce usable text; you have to run optical character recognition first. The good news on size, though: a scan of text is precisely the sort of file where compression delivers the most spectacular gains, often a factor of ten.

When the file is still too heavy

You have compressed it, and you are still over the limit. Four ways out, in order of effectiveness:

1. Split the document. Plenty of platforms will take several uploads rather than one large file. Splitting a PDF by page range settles the matter in one operation.
2. Delete what nobody needs. Blank separator pages, appendices nobody asked for, duplicates left over from an earlier merge: that is often 20 per cent of the file.
3. Go back to the source. If you still have the original document, re-export it with images at 150 DPI rather than trying to rescue a PDF already produced at high resolution.
4. Deal with the images before assembly. For a pack built from photographs, run them through compress an image — which works directly in the browser — before combining them into a PDF. The result is far better than compression applied to the finished document after the fact.

One tempting but false economy to rule out: using “print to PDF” to slim a file down. It flattens the document, breaks links and bookmarks and sometimes text selection too, with no guarantee of any real saving on size.

Five traps that cost you dearly

• Electronic signatures. Any rewrite of the file invalidates a cryptographic signature. Compress before signing, never after.
• PDF/A compliance. A document intended for legal archiving loses its compliance if the fonts or colour profiles are altered. Check the requirement before you act.
• Form fields. Depending on the method used, they can be flattened and become impossible to fill in. Test the output file before sending it.
• Password-protected PDFs. A compression tool cannot open an encrypted file. You have to unlock it first, which assumes the document is yours and that you know the password.
• Metadata. Compressing is not anonymising. The author's name, the software that created the file, and sometimes the EXIF data of embedded photos all survive the operation. If confidentiality matters, that is a separate step.

A final piece of common sense: an already optimised PDF will not compress twice. If a file only loses 2 or 3 per cent on a pass, the work has already been done and pushing harder will do nothing but degrade the images. On Convertu, the PDF tools run server-side: one free conversion every day with no sign-up, and beyond that a single subscription at €7 a year covers the whole catalogue.