Crop PDF Pages Individually, Not All at Once

Crop PDF pages individually and you can keep a portrait cover, a landscape invoice and a page with an over-wide margin together in one document, each trimmed to its own content. Crop them all the same way and at least one of those pages is wrong — usually by a wide margin, and usually on the page you were about to send.

Per-page cropping is the feature that separates a real PDF cropper from a canvas-resize box, and it is the one the biggest free tools tell you to work around. The other half of the problem is quieter: even a correctly drawn crop can land in the wrong place, because a PDF page is not the simple rectangle it looks like.

A page has two rectangles, and most tools only know about one

When you open a PDF in a reader you see one page. Inside the file there are two rectangles that matter, and a third idea on top of them.

• The MediaBox is the physical sheet — the paper the page is printed on.
• The CropBox is the part a reader displays. It is a window onto the sheet, and it is normally the same as the MediaBox until something changes it.
• The page may also carry a rotation, stored as one of 0, 90, 180 or 270 degrees. A page scanned sideways is often stored upright with a rotation instruction on top, so what you see on screen is the sheet turned, not the sheet rewritten.

This matters because a crop you draw on screen is in the rotated, visible space — and it has to be converted back through both the rotation and the visible rectangle's origin before it is written into the file. A tool that skips that conversion writes a plausible-looking box in the wrong coordinate space. The file opens, the page is the right size, and the content is off the edge.

There is a practical consequence for what you ask a tool to do, too. Cropping and trimming are two different jobs. Setting only the CropBox changes what a reader shows while leaving the sheet the way it was, which is what a print shop wants when the visible area is smaller than the paper. Shrinking the MediaBox to match makes the page itself smaller — which is what you want for a scan with a black edge. A cropper that only does the first leaves a stray centimetre of sheet on every page.

What the big online croppers actually do

The free tools are not vague about this. PDFresizer's crop page states it outright: "It is important to note that all pages in the processed documents will be cropped equally. If you require different parts of each page to be cropped, we recommend splitting the file before manually cropping each page." Its FAQ repeats the instruction: "The same crop settings are applied to all pages. If you need different crops for different pages, split the PDF first, crop individual pages, then merge them back together."

That advice is honest and it is also three separate operations — split, crop each piece, merge — for a job that is one drag per page. Smallpdf supports the closest thing to it, and its page describes the limit precisely: "Toggle to crop one page, or all pages at once." One page, or all of them. There is no mode for "each page its own way".

And the same PDFresizer page is explicit about where the file goes: "All files are processed on our server and automatically deleted within 1 hour of upload." Smallpdf says its files are "encrypted during processing and automatically deleted after one hour". Both are reasonable policies. Neither is the same as the file never leaving your machine, and the documents people crop — a passport scan, a signed contract, a shipping label with an address on it — are disproportionately the ones worth not handing to a server. PDFresizer also caps the upload at "Maximum combined file size: 100MB"; Smallpdf notes "some usage limits for free users".

How to crop PDF pages individually

1. Open the PDF in the tool. The file is read in the browser tab. Nothing is transmitted, which you can verify by disconnecting from the network after the page has loaded and cropping anyway.
2. Draw a box on the page you want to change. Drag over the area to keep, or press Detect margins to snap the box to the page's content. Drag an edge to adjust it.
3. Move to the next page and draw again. Each page keeps its own box, so page 3 can be cropped tightly while page 4 is left whole. The status line names the page it is about to change.
4. Decide the scope, then download. The scope control is what stops a per-page tool becoming tedious: leave it on this page for one-off crops, or switch it to this page and all after or every page to apply the current box to more pages at once.

One control is worth knowing about before you press download. Trim the page size too is on by default, which shrinks the sheet as well as the visible area. Turn it off when the sheet size has to stay put — a print-ready file whose visible area is deliberately smaller than the paper is the case that catches people out.

The run I measured, and the numbers it produced

Claims about coordinate mapping are worth nothing without a file to check them against, so here is one. The fixture is three pages of 400 × 600 pt (141.1 × 211.7 mm), 1,410 bytes, built so that the failure modes are visible rather than theoretical:

• Page 1 has a black rectangle inset exactly 50 pt from every edge, so a correct auto-crop has an origin that is equal on both axes.
• Page 2 carries a rotation of 90 degrees.
• Page 3 already carries its own CropBox, [40 60 360 560], and is never touched.

Run 1 — auto-detect on page 1. The default margin is 2 mm, which is 5.669 pt. The ink box starts 50 pt in, so a correct crop origin is 50 − 5.669 = 44.331 pt on both axes, and the visible area is 400 − 2 × 44.331 = 311.339 pt wide. Reading the downloaded file back with qpdf gives exactly that:

page 1  MediaBox [44.33070866141732,44.33070866141732,355.6692913385827,555.6692913385826]
        CropBox  [44.33070866141732,44.33070866141732,355.6692913385827,555.6692913385826]
page 2  MediaBox [0,0,400,600]   CropBox (none)                Rotate 90
page 3  MediaBox [0,0,400,600]   CropBox [40,60,360,560]       Rotate 0

Three things are being asserted at once there, and all three matter. The sheet and the visible area agree, so the trim really happened. Pages 2 and 3 are untouched — the per-page promise, checked on the pages that should not move. And page 3's original CropBox survived the round trip, which a tool that rebuilds every page would have silently discarded.

Run 2 — a hand drag on the rotated page. Page 2 is displayed 600 pt wide and 400 pt tall because of the rotation. Dragging from 25% to 75% of the displayed page should therefore land at x from 100 to 300 and y from 150 to 450 in page space — the numbers swap axes precisely because the page is turned. The file says:

page 2  MediaBox [100.19723865877711,150,299.8027613412229,450]   Rotate 90

The few hundredths of a point come from rounding the drag to whole pixels; the mapping itself is exact, and the rotation is preserved rather than flattened. That is the assertion the whole coordinate conversion exists for, and it is the one a tool that ignores rotation fails while still looking like it worked.

Both outputs pass qpdf --check with "No syntax or stream encoding errors found", and both keep all three pages.

Why the cropped file is slightly larger, not smaller

This is the measurement that surprises people. The 1,410-byte input became 1,443 bytes after run 1 and 1,447 after run 2 — a crop made the file bigger by a few dozen bytes.

That is the correct behaviour and it is easy to reason about once you see it. The page boxes are a handful of numbers stored in the page dictionary, and writing an explicit CropBox where none existed adds numbers to the file. What does not change is the content stream: the text, fonts, images and vector art are copied through byte for byte, so nothing is re-rendered and nothing is re-compressed. A cropped scan keeps its full resolution, and its text stays selectable and searchable.

So crop first and compress afterwards, not the other way round. Cropping defines the area the compressor then works within, and a compressor run first will have spent its effort on the margin you were about to cut away.

Detect margins: measured against the ink, not assumed

An "auto-crop" that assumes a uniform white margin is defeated by the four cases that actually turn up in a scanner tray: a black edge down one side of a flatbed scan, a fax header above the text, a photograph that bleeds to the page edge, and a signature that hangs outside the text block. A fixed margin either leaves the black edge or eats the signature.

Detecting the content properly means rendering the page and finding the bounding box of every pixel that is not paper-white, then leaving a margin around that. In the run above the box landed exactly on the ink, which is why the arithmetic works out to 44.331 pt rather than to a round number: the tool followed the content instead of assuming where it was. A page with nothing on it says so and is left whole rather than being cropped to nothing.

Wrapping up

The gap between a working PDF cropper and a frustrating one is not the drag interaction, which everyone gets right. It is the two things that are invisible until they go wrong: whether each page can keep its own box, and whether the box you draw survives the page's rotation and its existing visible area.

Draw the box on the page that needs it, check the status line names that page, leave the scope on this page, and read the result back if it matters. And if the file is a scan of something you would rather not upload, that is a reason to use a tool that never asks you to.