Why is my PDF so big?

What is actually in a large PDF

A PDF is a bag of objects. Some of them are the words on the page, some are the fonts those words are drawn in, and some are images that were pasted or scanned in. You can walk that bag and add up who owns how many bytes, which is what these are — every raw stream in the file, attributed to what it is.

Read the first row slowly. That manual is 1,502 pages. Every word in it, every position, every line and rule — the entire drawing instruction set for fifteen hundred pages — is 5.1 MB. The twenty-one embedded font programs are 87 KB. The 3,466 embedded images are 37.8 MB. You could delete the text of the whole book and save a tenth of the file.

Embedded fonts get blamed constantly and almost never deserve it. A subset font program is tens of kilobytes and it is shared by every page that uses it, so its cost does not grow with the document. A photograph's cost grows with every one you add.

So why did compressing it do nothing?

Because lossless compression cannot compress a JPEG. Of those 37.8 MB of images in the manual, 95.0% were already stored as JPEG streams. JPEG has already taken out everything a general-purpose compressor knows how to find; running deflate over the result returns approximately nothing.

Here is what a genuinely lossless pass gets you. This is our own "Light" mode, which is a plain re-save: reload the object graph, drop the document metadata, write it back using object streams. Nothing is resampled and nothing is re-encoded, so every pixel and every selectable character survives exactly.

Two of those four gave back two hundred bytes. That is not a broken tool. It is what lossless compression has left to offer a file that is one large already-compressed image and almost nothing else: the picture is untouchable and there is no structural slack to reclaim. On files like these a rewrite can even come out slightly bigger, which is why our compressor checks the result against your real source bytes and hands the original straight back rather than shipping you a larger "compressed" file.

And notice where the one good result came from. The 17.1% on the last row is entirely structural: 44% of that document was cross-reference tables, dictionaries and object headers rather than content, and packing those into object streams is exactly what a lossless pass is good at. That is the ceiling. If a tool quotes you 70% and promises your text stays selectable, one of those two things is not true.

The only lever that actually moves it

Fewer pixels, or more loss in the ones you keep. There is no third option — the size of an image file is set by how much information is in it, and the only way down is to have less.

Two files we measured independently landed on almost the same number: about 0.07 bytes per pixel for photographic and screenshot content stored as JPEG. A clean scan of black text on white paper compresses far better — the 150 dpi A4 page above is about 0.02 bytes per pixel. Either way, halving the resolution quarters the pixel count, and the file follows.

That is what a "strong" or "aggressive" compression setting is doing, whatever it is called. Ours re-renders every page to a JPEG and rebuilds the document from those images — at 150 dpi and quality 0.82, 110 and 0.60, or 90 and 0.45, depending on which of the three you pick. On a scan the gains are large and immediate, because a scan is nothing but pixels and you are throwing away three quarters of them.

The trade nobody states plainly

Re-rendering the pages destroys the text layer. Before, the words were characters with positions, and Ctrl-F found them. After, they are shapes in a photograph of a page. Search finds nothing, copy-paste gives nothing, a screen reader reads nothing, and it cannot be undone without running OCR over the result.

This is why "compress a PDF" is really two unrelated jobs:

• A scanned PDF is already all image. There is no text layer to lose — unless it has been OCR'd, in which case rasterising throws that away too. Downsampling is the right tool and it works: this is the case where the big numbers are honest.
• A text PDF has almost nothing to compress. Its content streams are already deflated — a lossless pass over the 101-page e-book above recovered 98 bytes. If yours is somehow 40 MB, that is not the text; someone dropped full-resolution photos into it. Find those, rather than rasterising fifteen hundred pages of perfectly good type into pictures to claw back a tenth of the file.

Order matters if you want both. Run OCR first, at the resolution you scanned at, and compress afterwards — the searchable text layer is characters, not pixels, and survives the rasterising intact. Compress first and you have thrown away the detail the recogniser needed.

What cannot be done

If you have 40 MB of 600 dpi scans, nothing takes it to 2 MB intact. At a constant bytes-per-pixel that is keeping about one pixel in twenty, which means dividing the resolution by roughly four and a half — 600 dpi down to about 130. Below 300 dpi, OCR accuracy falls off a cliff because the letterforms stop being distinguishable, and 130 dpi is visibly soft on anything you print.

There is a real answer, it is just not a compression setting: scan at 300 dpi in the first place, in greyscale rather than colour if the page is black ink on white paper. 600 dpi quadruples the pixel count of every page for a gain nobody sees on a document, and it is the most common single reason a folder of scans is enormous.

Find out before you compress

Every number on this page came from counting what was in the file, and you can do the useful half of that yourself in about ten seconds. Pull the embedded images out and look at their pixel dimensions: a 4000×3000 photo in a document that prints it two inches wide is 24 megapixels doing the work of one, and that single object is usually most of your file.

• See what is in there. Extract the embedded images — they come out at their own resolution, not as pictures of the pages, so the oversized one is obvious.
• Make it smaller. Reduce the file size — lossless first, and only go to the image setting once you have accepted what it costs.
• Drop what you do not need. Delete pages or split the file. Sending the four pages someone asked for instead of all ninety beats any compressor, costs nothing in quality, and is the option people skip.

All of these run in your browser. Your files are never uploaded — everything runs on your device. For the scanned contracts, deeds and medical records that make up most oversized PDFs, that is rather the point.

Questions

Why is my PDF so big when it is mostly text?

Because the text is almost never the reason. In a 1,502-page software manual we measured, every page content stream in the document — all the words, positions and drawing instructions — came to 5.1 MB of a 49.2 MB file, and the embedded font programs came to 87 KB. The embedded images came to 37.8 MB. Deleting every word would save about a tenth of the file.

Why did compressing my PDF do nothing?

Because lossless compression cannot compress a JPEG. 95% of the image bytes in that 49 MB manual were already JPEG-compressed streams, and running deflate over data that is already compressed returns roughly nothing. A lossless re-save of that file saved 3.6%. The savings a lossless pass does find come from structural slack — object streams, stripped metadata, deduplicated dictionaries — not from the pictures.

Why did my PDF get bigger after I compressed it?

For the same reason, taken one step further. If a file has few objects and one large already-compressed image, there is no structural slack left to reclaim, so a rewrite is close to break-even and can land on the wrong side of it — a 609,577-byte one-page sheet we re-saved losslessly came back at 609,367 bytes, a saving of 210 bytes. A compressor should compare its output against your real source bytes and hand the original back when it loses; ours does.

How much smaller can a scanned PDF actually get?

As much as you are willing to throw away, and no more. File size for scans tracks pixel count almost linearly — we measured about 0.07 bytes per pixel for photographic content and about 0.02 for a clean text scan, across separate files. Getting 40 MB of 600 dpi scans down to 2 MB means keeping roughly one pixel in twenty, which is about 130 dpi. That is below the resolution at which OCR reads reliably and it looks it. Any page promising 40 MB to 2 MB with no visible loss is lying.

Does reducing PDF file size lose quality?

Only the lossy route does, and only the lossy route gives you a big number. A lossless re-save keeps every pixel and every selectable character but typically returns single-digit percentages. Re-rendering the pages as images gives you the dramatic reduction and costs you the resolution and the text layer — after that, Ctrl-F finds nothing.

What resolution should I scan at?

300 dpi for anything you may want to search later. Below roughly 300 dpi, OCR accuracy falls off because the letterforms stop being distinguishable. 600 dpi quadruples the pixel count for a gain you will not see on a document and is the single most common reason a scan folder is enormous.

How do I find out what is making my PDF big?

Pull the embedded images out and look at their dimensions. An image placed at 4000×3000 in a document that prints it two inches wide is 24 megapixels doing the work of one, and it is almost always where the bytes went. Our image extractor lists every embedded image at its own pixel size, in the browser, without uploading the file.

Figures measured August 2026 on four real documents. Byte composition by walking each file's object graph with pdf-lib and attributing every raw stream to images, font programs, page content streams or other; the remainder to the on-disk size is cross-reference and dictionary overhead, shown as "everything else". Lossless results are the exact "Light" path this site's compressor ships. Percentages are of the whole file unless stated.