← All posts

Why an edit made your scanned PDF bigger

21 August 2026

You had a scan. It was 4 MB, two hundred pages, and it opened instantly. You put a black box over an account number, or ran Sanitise, or straightened a few crooked sheets. The file came back at 40 MB.

Nothing was added. The page count is the same, the pages look the same, and one of them has a black rectangle on it that occupies about a thousand bytes' worth of ink. Ten times the size, for that.

The Adobe forum threads about this get answers like "run Reduce File Size" and "try Optimise PDF", which sometimes helps and never explains anything. The explanation is worth two minutes, because it tells you which edits will do it to you again and which will not.

What the scanner wrote, and why it was so small

A scanner does not save a picture the way a camera does. It uses encoders built for one job — pages of black marks on white paper — and they are extraordinarily good at it.

• CCITT Group 4 is the fax encoder. Every pixel is black or white, and it stores runs rather than pixels: this many white, this many black, and the next line is mostly like the one above. A typed A4 page at 300 dpi is 2,480 × 3,508 pixels — 1.1 MB if you wrote out the bits — and G4 usually brings it in between 30 and 80 KB.
• JBIG2 does better still. It notices that the page contains the same letter e four hundred times, stores the shape once in a symbol dictionary, and then records where each copy goes. That dictionary can be shared across every page in the document, so page two hundred costs less than page one.
• JPEG handles the greyscale and colour scans, at a quality setting your scanner picked to suit paper — usually around 60, not 90.

Four megabytes for two hundred pages is roughly 20 KB a page. That is what those encoders buy you.

What the edit did to it

Any operation that has to change what a pixel looks like must first decode the image back to a plain grid of pixels, and then write it out again. The writing-out is where the size goes, and three things usually go wrong at once.

The colour space gets promoted. Editors draw into an RGB canvas, because that is what everything else in their pipeline expects. A one-bit page goes in at one bit per pixel and comes back at twenty-four. Before any compression at all, that is a factor of twenty-four on the raw data.

The encoder changes. Almost nothing writes CCITT or JBIG2 back out. What you get instead is Flate — ordinary zip compression on raw pixels — or a fresh JPEG. Zip is hopeless on a scan, because what looks like a white page is actually speckle from the sensor and there is no repeating pattern in it to find. A JPEG is much better, but it is now encoding grain at whatever quality the editor defaults to, which is higher than the scanner used, and grain is the single worst thing you can hand a JPEG encoder. Either way the shared symbol dictionary is gone: each page is now encoded on its own.

Nothing downsamples. The re-encode happens at the original pixel dimensions. A 300 dpi scan comes back as a 300 dpi picture, because throwing away detail is a decision no editor will make for you silently.

Twenty KB a page becomes several hundred KB, or a couple of megabytes if it landed on Flate RGB. That is the 2x to 10x people report, and occasionally worse.

The edits that trigger it

• Redaction. The whole point is that the marks underneath are destroyed rather than covered, so on a scan the image itself has to be altered and rewritten. Some tools rebuild only the affected page; some rebuild every page in the file.
• Sanitise, or Remove Hidden Information. It rewrites the document wholesale.
• Straightening. Turning a bitmap means resampling it, so a corrected page is a new picture — including what that does to any text layer on it. Our Deskew PDF renders corrected pages at 200 dpi in grey and copies untouched pages across byte for byte, which is why the page range is the setting that decides how much the file grows.
• Greyscale conversion, flattening, and burning in annotations. Each one replaces drawn content with a rendering of it.
• A plain Save, in some editors. An incremental save appends the new objects and leaves the old ones in place, so the file can carry both copies of the image — one of several reasons a file grows when you expected it to shrink.

Operations that touch no pixels cost nothing: rotating by 90 degrees, reordering pages, editing metadata, adding bookmarks. If the file grew after one of those, it was the save, not the edit.

Check what you actually have

Our PDF inspector reads page count, page sizes and whether there is a real text layer, in the browser, without uploading anything — useful for the basics, but it does not report image encodings.

For those, install poppler-utils and run pdfimages -list before.pdf, then the same on the file that came back. It prints one line per image with the encoding, the bits per component, the pixel dimensions and the size. Watching ccitt, 1 bpc, 34 KB turn into image, 8 bpc, 2,100 KB tells you the whole story in one screen, and tells you whether the growth is colour promotion, encoder change or both.

Getting the size back down

The damage is done — those pages are ordinary pictures now — but ordinary pictures are exactly what compression is good at.

1. Run Compress PDF at the defaults: balanced, 150 dpi. It works out how large each picture is drawn on the page, converts that to a resolution, and re-saves anything above the ceiling as a JPEG. A 300 dpi full-page scan is well above it, so it gets halved in each direction and re-encoded — usually the largest single win available.
2. Tick "turn pictures grey" if the scan is of black-on-white paper. Dropping three channels to one takes off most of what the colour promotion added, and on a monochrome original you lose nothing you can see.
3. Read the notes, not just the number. They say how many pictures were re-saved and how many were already at or below the target. If it hands your file back unchanged and says so, there is nothing left in the images and you should stop — that is a specific finding, not a failure.

If you need tighter control than the compressor gives you

When the pages are already pictures and you want to choose the resolution yourself, PDF to JPG renders each page at anything from 36 to 400 dpi at a JPEG quality you set, and JPG to PDF puts them back into a document, embedding each JPEG byte for byte rather than encoding it a third time. More steps, and you can see exactly what 120 dpi looks like before you commit two hundred pages to it.

Greyscale PDF is the blunt version of the same thing: every page redrawn at 150 dpi as an eight-bit grey image, no options. It is the right tool when a scanner has left a colour cast across a document that is meant to be monochrome and you need every trace of it gone. It writes those pages losslessly, though, so run compress afterwards or you may not gain much.

What none of it gets back

The detail thrown away by the first re-encode is gone, and this second pass throws away more. If the document is evidence, a signed record, or anything that might be examined closely later, the file to keep is the one from the scanner.

Which is the real lesson for next time: do the destructive edits once, at the end, on a copy, and keep the original untouched. Redact, sanitise, straighten and flatten in a single pass rather than saving between each one, and set a page range wherever a tool offers you one. Every page you leave out of the range keeps the encoding the scanner gave it, and that encoding is better than anything that will replace it.