Why your PDF won't get smaller, and what actually works

Search any support forum for "reduce PDF size" and you will find the same story told again and again. Someone runs the shrink command, the file barely moves, they try another tool, it gets bigger, and an hour later they upload the original anyway and hope for the best. The advice they get back is a pile of settings, filters and round trips through other programs, often contradicting each other.

This post goes through some of those threads, explains why the usual fixes fail for some files and work brilliantly for others, and then shows measured results from four test documents we built to match the patterns people describe. By the end you should be able to look at your own file, work out which kind of heavy it is, and pick the fix that suits it.

What people actually run into

Read the five together and the pattern is hard to miss. Nobody in them knew what was making the file heavy. Each person reached for a general purpose shrink command, got an unpredictable result, and had no way to tell whether the problem was the tool or the file. The tool was usually fine. The file was just a different kind of heavy than they assumed.

A PDF is a box, and what is inside decides everything

A PDF looks like a single thing, but it is a container. Open it up and there are only a handful of ingredients, and nearly all of the weight comes from one of them.

• Pictures. Photos, scans, logos and screenshots. A single phone photo can be three megabytes, and a document with a few of them gets big very quickly.
• Fonts. Each typeface used is usually stored inside the file so the document looks the same everywhere. A document that mixes many fonts, especially large ones for other writing systems, carries all of them.
• Text and drawing instructions. The words themselves and the lines, boxes and shapes. This is almost always the smallest part. Twenty typed pages can be well under a tenth of a megabyte.
• Leftovers. Earlier versions of edited content, thumbnails, application data and objects that nothing on any page points at any more. Files that have been edited and saved many times collect these.

Once you see it that way, the forum threads make sense. A shrink command that mostly works on pictures does wonders on a file full of photos and nothing at all on a file whose weight is leftovers. A command that redraws pages as pictures rescues a scan and ruins a typed document. There is no single best setting because there is no single kind of PDF.

The one number that explains most big files

The most common cause of an oversized PDF is a mismatch between how big a picture is and how big it is shown. A modern phone takes photos that are 4000 pixels wide. Put one on a page at three and a half inches wide and the file still carries all 4000 pixels, squeezed into that small space. The reader sees a small photo. The file keeps the full weight.

That is the whole story of the Adobe thread about solar guides. Setting a downsampling target helps only if the software actually applies it to every image, and the reply to that thread recommended resizing the images to the size they are displayed at. The fix is cheaper at the source: shrink the photo before it goes into the document, and the document is small from the start.

What we measured

Rather than guess, we built four test documents to match the situations in those threads and ran them through the approaches people actually use. Everything below was measured, and the method is described under the chart so you can judge it. Your files will differ in the details, but the shape of the results is the useful part.

Four different files, four different answers. Redrawing pages as pictures was spectacular on the scan and the photo report, and a disaster on the typed document, where it took a 24 KB file to nearly six megabytes and removed the ability to select a single word. Resizing the photos before building the document did better than redrawing in every way for file A: it was smaller and the text was still real text. And a clean save was the only thing that touched file D, because there was nothing in it to compress. All of its weight was data that nothing used.

Work out which kind of heavy yours is

Two minutes of looking saves an hour of trying. Go through these in order and stop at the first one that fits.

1. 1Check whether you can select the textOpen the PDF and try to highlight a sentence. If you can, the pages have real text. If the cursor will not catch any words, every page is a picture, which is how scans behave.
2. 2Count the pictures and divideTake the file size and divide by the number of photos. If six photos explain most of 18 MB, you have found it. A file with no photos and a large size points at leftovers or fonts instead.
3. 3Look at how it was madeA document exported from a design or office program usually carries its pictures at full size. A document that was scanned is all pictures. A document that has been signed, annotated and edited several times is the likely home of leftovers.
4. 4Note the limit exactlyPortals state limits in kilobytes or megabytes, and a megabyte is not always the same size. Aim for around 80 percent of the stated number so a small difference in how it is counted cannot reject the file.

The right fix for each kind

Photos placed in a typed document

Fix it where it starts. Shrink the photos before they go into the document, to roughly 150 pixels per inch at the size they will appear, then build or export the document again. The text stays real text and the file is small for good. If you no longer have the source document, this is the case where redrawing pages is a fair fallback, with the trade that the text becomes a picture.

A scan

A scan is already a stack of pictures, so redrawing pages loses nothing that was there to begin with. Use the gentlest setting that clears the limit, because every step down makes small print softer, and then read the result at full size before you send it. If the scanner can be set to 150 or 200 dpi and rescanned, that beats any later shrinking.

A document that will not shrink at all

If the commands move nothing, suspect leftovers, exactly as in the second thread above. Write the document out as a clean copy so that only what pages actually use is kept. It is the same idea as the expert's advice to save under a new name, without needing to open anything. One thing to know: a clean copy also clears the author name, dates and other document details, which is usually what people want before sending a file anyway.

A document that is simply too long for the limit

Sometimes the content is the content. If a portal takes several files, splitting a long document into two or three parts is a legitimate way to stay under each limit, and it keeps every page sharp.

Where our tool fits, and where it does not

We make a compress tool, so it is fair to be plain about what it does. It redraws every page as a picture, which is why it works so well on scans and photo heavy files and why it is the wrong choice for a typed document. After it runs, the text can no longer be selected, searched or read aloud. It also redraws at a screen resolution, not a print one: the gentle setting is around 115 pixels per inch and the smallest is around 65. That is fine for a portal upload that someone will read on a screen. It is not what you want for something to be printed.

It also runs entirely in your browser, so the document is never sent anywhere. That matters here because the files people most need to shrink tend to be the ones they least want to upload: a passport scan, a signed contract, a medical letter. One of the threads above includes a recommendation for online compressors, and for a document with personal details in it, sending the file to a stranger's server is a real cost that rarely gets mentioned.

Mistakes that cost people an hour

• Compressing the result again. Each pass through a picture based shrink loses a little more detail. Go back to the original and choose a stronger setting once.
• Zipping the PDF. A zip file rarely saves much, because the pictures inside are already compressed, and many portals will not accept a zip at all.
• Renaming a file to change its type. A file named something.pdf that is really a photo is not a PDF, and a portal that checks the contents will reject it.
• Judging by file size alone. A 1 MB file that is unreadable has failed. Always open the result at full size and read the smallest text before you send it.
• Misreading the unit. Kilobytes and megabytes are a factor of a thousand apart. Check which one the form means.
• Deleting pages to shrink it. As the first thread shows, removing pages does not guarantee a smaller file, and it can change what the document says.

A short routine to keep

Check whether the text is selectable. If it is, find out whether the weight is photos or leftovers. If it is photos, shrink them at the source. If it is leftovers, write a clean copy. If it is a scan, redraw it at the gentlest setting that clears the limit, and read the result before sending. Keep the original in case you need to start again. That is the whole method, and it works because it begins by looking at the file instead of reaching for a setting.