Cropping a PDF: What Stays Hidden in the File

Cropping a PDF feels like cutting a photograph: whatever is outside the frame is gone. With a PDF that is not what happens, and the difference matters when you crop something out because you do not want people to see it.

What a crop actually does

A PDF page is a set of drawing instructions plus a description of the area that should be shown. Cropping changes the second part. The page now displays a smaller rectangle, and viewers and printers respect it, so the trimmed margin, the colleague's name, or the price column disappears from view.

The drawing instructions are untouched. The text and images outside the rectangle are still in the file, just not shown. HerePDF's crop mode works this way, and its FAQ says so plainly. Anyone with a PDF editor that can adjust the page area can widen it again and see what you trimmed, and some programs that read the file directly will list the trimmed text even though your viewer does not show it. The measurements below put numbers on both.

What we measured: what a crop leaves in the file

We applied HerePDF's crop to 2,889 real PDFs (37,682 pages) three ways: a tenth trimmed off every side, the bottom quarter cut off, and only the top half kept. Then we compared each result with its original.

Nothing on the page itself changes. In 2,889 of 2,889 files every page's content stream is byte-for-byte the original, and the MediaBox, the full sheet the page was made on, is untouched in 2,889. The visible frame was narrowed in 2,889 of them. Putting each page's original CropBox back with a single pdf-lib call restored the original visible size in 2,889 of 2,889. That is all it takes to undo a crop.

Cutting a strip cuts text, nearly always. 2,818 of the files have text on their first five pages. Cutting off the bottom quarter removed at least one run of text from view in 2,788 of them (99%), 273,528 runs in all, where a run is one piece of text such as a word or a line. A tenth off every side did so in 94% of them, and keeping only the top half in 100%. A crop is almost never a trim of empty margin alone.

Who can still read the cut-off text depends on the program. In 400 files, for the bottom-quarter crop, we took the first cut-off run that was not also visible elsewhere on the page and looked for it in the output with five readers. A reader counts only in the files where it also found the run in the original, so a font it cannot read does not make a result look clean.

Your viewer may not show you. PDF.js returned none of the cut-off text, because it leaves out text outside the visible page. Ghostscript and pdfminer returned all of it, even when told to respect the CropBox. So selecting across the trimmed area is not a test of whether a crop removed anything: in a PDF.js viewer the text will not highlight, and it is still in the file. We did not test Acrobat, Preview or the viewers built into Chrome and Edge, so we do not say what they do.

A crop does not make the file smaller. The cropped files came out a median 89.4% of their original size, because HerePDF rewrites a file when it saves it. That is not the trimmed content going: keeping only the top half gave a median 89.4%, the same as trimming a tenth off each side (89.4%).

The limits: these are old government documents, the three crops are ours and not ones people chose, and the readers are not every program. 106 of the 2,995 files are not counted: 99 were encrypted and the rest could not be read. The file names are not published, only counts; the data and the method are there to check against.

Resize is the same in one respect

The resize tool scales every page to a paper size such as A4 or Letter, matching each page's own orientation so a landscape page is not squeezed into a portrait shape. In its Fill mode the scaled page can overflow the target size, and what overflows is clipped from view rather than deleted. It happens less often than a crop: Fill to A4 clipped some text in 548 of the 2,889 files and Fill to Letter in 128, since most pages have a margin to spare. When it did, the text was still there: of 44 files with clipped text that we checked, Ghostscript found it in 44 and pdfminer in 44. Nothing is thrown away either way, and the file does not get smaller.

When cropping is the right tool

Cropping is right when the goal is appearance: removing scanner borders, trimming excess white margin, cutting a browser header off a printed-to-PDF web page, or fixing a page that prints with a stray edge. In those cases it does not matter that the trimmed area is technically still there. If you are unsure of sizes, PDF page sizes explained covers points, paper sizes, and why pages print at the wrong scale.

When it is not

If the content you are cropping out is sensitive - an address, an account number, another person's details - cropping is not enough. The same confusion between "not visible" and "not there" is what why hiding text in a PDF usually doesn't remove it describes for black boxes and highlighters. For that you need redaction that removes the content: the redact tool renders each marked page, paints the black boxes into the image itself, and rebuilds the page from that image, so the original text no longer exists on that page. It also drops annotations, links and form fields on a redacted page, and it does not change document properties, which is a job for the metadata tool.

Why viewers make this confusing

Because every mainstream viewer respects the visible area, a cropped PDF looks final. Nothing on screen hints that there is more, and in some viewers even selecting the text will not reveal it. That is exactly why the mistake is so common: people crop out a name, see it vanish, and send the file with confidence. The file is not lying to them - the visible result is real - but the visible result and the stored content are two separate things, and the difference only shows up when someone with a different tool looks.

Practical examples

Cropping a scanned form to remove the scanner's dark edge is a perfect use: the dark edge is not sensitive, and nobody minds that it still exists somewhere in the file. Cropping a spreadsheet printout to drop the columns that show salaries is the opposite case. The columns are hidden from the page but remain as text in the file, and some extraction programs will list them. The test is simple: would it matter if the trimmed part were recovered? If yes, crop is the wrong tool.

Cropping every page the same way

HerePDF's crop mode applies one box identically to every page. That suits documents whose pages share a layout, like a batch of scans from the same machine. It is a poor fit for a mixed file where some pages have content near the edges that a shared box would cut. If pages differ, split them into groups first with the split tool, crop each group, and merge the results back together in order.

Resize and orientation

When you resize to a paper size, each page is scaled to fit that size in its own orientation, so a landscape page stays landscape. That avoids the sideways squeeze that a naive resize would cause. If a page is the wrong way round to begin with, fix that first with the rotate tool.

A quick check

Do not rely on selecting text across the trimmed area: as measured above, a viewer built on PDF.js will not select it, and the text is still in the file. Assume a crop removed nothing. If you need to know what a program that ignores the page area would list, run the file through one: Ghostscript's text output, for example, gs -q -dNOPAUSE -dBATCH -sDEVICE=txtwrite -sOutputFile=- file.pdf, prints the trimmed text too, and that is how we measured it. Or skip the check and use redaction for anything you could not afford to have recovered.