PDF too large to upload? Seven ways to shrink it

A PDF is a container, and containers do not have a size — their contents do. Every technique below works by removing or shrinking one specific kind of content, which means the useful question is not “how do I compress a PDF” but “what is taking up the room in this PDF”.

Answer that first and you will usually find one technique that solves the whole problem, instead of applying seven and hoping.

Find out what you have, in ten seconds

Open the file and try to select a line of text with your cursor.

If the text highlights, you have a real text PDF. The words are stored as characters, the layout as instructions. Text is almost free — the entire text of a fifty-page report is a few tens of kilobytes — so whatever is making the file large is images, fonts, or leftovers. All three are fixable at little or no visible cost.

If nothing highlights, you have a scan: photographs of paper in a PDF wrapper. Now the images are the document, and every technique that shrinks them shrinks legibility too. Different problem, different economics, and the ceiling on what you can achieve is much lower.

Everything below is ordered by what it costs you. Work down the list and stop when you are under the limit.

1. Strip what nothing reads

Free. No visible change whatsoever.

A PDF accumulates: XMP metadata, an embedded page-thumbnail cache, the previous revision of every edit if it was saved incrementally, unused objects nothing references any more, an output-intent colour profile, JavaScript, form definitions for a form nobody filled in.

Individually these are small. Together they routinely account for 50 to 200 KB, and on a file produced by a chain of editors they can be most of it. Rewriting the file with only the reachable objects — sometimes called linearising or garbage-collecting — costs you nothing at all, because nothing that renders is touched.

Run this before anything else. On a text-heavy document it occasionally solves the entire problem.

2. Subset the fonts

Free in appearance, sometimes enormous in effect.

An embedded font can carry every glyph it defines — Latin, Cyrillic, Greek, mathematical operators, arrows, box-drawing characters — when your document uses about eighty of them. Four weights of a large family can be 600 KB of a 900 KB file.

Subsetting keeps only the glyphs actually used and discards the rest. The document renders identically. Most modern exporters subset automatically; plenty of older ones, and a surprising number of enterprise report generators, do not.

The one caveat: if the document is a form that other people will type into, subsetting can leave the form unable to display characters nobody has typed yet. For a form, keep the fonts whole.

3. Downsample the images

Cheap, and usually invisible. This is the big one on most text PDFs.

A photograph pasted into a report at its original 4000-pixel width, displayed two centimetres wide, is storing roughly a hundred times more detail than it can possibly show. Downsampling to the resolution the page actually needs — around 150 dpi for on-screen reading, 300 dpi if it will be printed properly — removes the excess.

The arithmetic is worth internalising because it is not intuitive: halving the resolution removes three quarters of the pixels, because area scales with the square. Going from 600 dpi to 150 dpi removes about 94%. This is why downsampling beats quality reduction so consistently — it is a much steeper lever, and it does not introduce artefacts, it just stops storing detail nobody sees.

4. Re-encode the images harder

Cheap at first, then not. This is where quality starts to go.

Once the images are at a sensible resolution, the remaining lever is how hard each one is compressed. Somewhere around JPEG quality 75 the damage becomes visible in gradients and skin tones; around 60 it becomes visible everywhere; below 50 the document looks cheap.

Two things to watch. Text inside an image — a screenshot of a table, a diagram with labels — degrades much faster than photographic content, so a setting that looks fine on the photo on page 3 can make page 7 unreadable. And re-encoding an image that is already a JPEG compounds the artefacts of the first encode rather than replacing them.

This is the point at which a target-size tool earns its keep: give it the number the portal demands and let it search for the settings that land under it, instead of guessing at a slider and re-exporting five times. The compressor does the first three steps before it touches this one, which is the right order.

5. Send fewer pages

Free, and the most underrated option on the list.

A great many oversized uploads are oversized because they contain more than was asked for: the CV plus three certificates plus a covering letter, when the form wanted the CV. Proof of address means the page with the address on it, not the whole statement.

Extracting the pages you need is lossless — nothing is re-encoded, so the pages that survive are byte-for-byte what they were — and it is frequently a 90% reduction for zero quality cost. It is also better for the person reading it.

Check what was actually requested before you compress anything. It is the only technique here with no downside at all.

6. Rebuild it from the source

Free if you have the source, and it is the correct answer more often than people expect.

If the file began life as a .docx, a spreadsheet or a design file, exporting a fresh PDF from that source will almost always beat compressing the one you have. You get subset fonts, sensibly sized images and no accumulated history, in one step.

The extreme version of this: if your PDF is a scan of a document you printed from a file you still have, stop scanning. Export the original to PDF. A two-page text CV exports at 80 to 150 KB with a photograph in it; the scanned printout of the same CV is 6 MB and worse in every way.

7. Accept the floor, and work around it

Some files cannot get there, and it is better to know that than to keep turning the quality down.

A dense multi-page scan has a genuine floor set by legibility. You can force it under any number you like, but there is a point below which a human being cannot read it, and a document nobody can read has not been successfully submitted.

When you hit that floor, the moves are: split it and send the parts separately if the recipient allows; convert to greyscale if colour is not carrying information; re-photograph in better light, which sounds cosmetic and is not — even lighting produces dramatically less noise for the encoder to preserve; or ask the recipient whether they can take it another way. Portals frequently have an email fallback that nobody advertises.

Two things that catch people out

Merge before you compress, not after. Compressing three files separately and then merging them gives you three copies of the same embedded fonts. Merging first lets the compressor deduplicate across the whole document, and shared fonts are often the largest single object in the result.

Rasterising is a last resort, not a shortcut. Turning every page into an image with PDF to JPG and rebuilding does sometimes produce a smaller file, and it destroys the text layer permanently — the document stops being searchable, selectable and accessible. Do it only when nothing else works, and keep the original.

And keep the original regardless. The compressed copy is for the portal. It is not your archive.