- Cropping writes a CropBox to each page: the visible window shrinks, the MediaBox and every text or image stream stay untouched — measured, the page content stream came out byte-identical
- The tool rewrites the whole file, so size moves either way: −26.8% to −43.6% on Chrome-printed PDFs, +12 to +20 bytes on files pdf-lib wrote itself
- A control run that cropped nothing lost almost the same bytes as the real crop (42,131 vs 42,135 bytes) — the saving is the re-save, not the crop
- Four controls decide the result: 8 drag handles, the 0.5" / 1" presets, an All Pages / This Page scope and a range field
- Presets are absolute: clicking 0.5" twice leaves the same 524 × 770 box. Re-opening a cropped file and applying it again does shrink it (524 → 452)
- One box is measured on the previewed page and reused on every selected page — that is why mixed-size files crop unevenly
- A range that matches no page (
9-99on a 4-page file) falls back to cropping every page - A 100 × 100 pt page cannot take the 1" preset — the readout turns negative (−44 × −44 pt) and the run is refused with "Invalid crop dimensions"
- Cropping is not redaction: the hidden area stays in the file. Only a rebuilt page (print to PDF) or a raster round-trip removes it
- Order matters: rotate → crop → page numbers → compress → merge. Page numbers follow the crop box; a watermark does not, so re-check a stamp after cropping
How to Crop a PDF in 4 Steps
Open the editor, place the box, choose the pages, crop. Timings below are from runs on the live tool.
Upload and open the editor
Drop the file on the upload card (or import from Google Drive / Dropbox), then press Open Editor. Nothing is uploaded — the PDF is read straight into browser memory, so even a few-hundred-megabyte scan never leaves the machine.
Place the crop box
- Drag any of the 8 handles (4 corners, 4 edges) on the page preview, or drag inside the box to move it
- 0.5" Margin or 1" Margin — one click, applied evenly to all four edges
- Reset puts the box back to the full page
Choose which pages get cropped
All Pages applies the box to the whole document; This Page only to the page on screen. Need a subset? Type a range — 3, 5-12, or 1, 4, 6-9, 15. An empty range field means every page.
Crop and export
Press Crop, then Export — the green button in the action row. Measured on this build: eight fixtures from 1 to 12 pages finished in 0.13–0.54 s each. The output is saved as yourfile_cropped.pdf and the original stays untouched on your disk.
What a CropBox Actually Changes (Measured)
One dictionary entry per page — no pixel is re-encoded. The file size still moves, and the reason is not the crop.
Each PDF page carries a MediaBox (its physical size) and an optional CropBox (the window a viewer may show). This cropper writes a CropBox and leaves the MediaBox alone, so a US Letter page still measures 612 × 792 points while the viewer shows the inner 540 × 720. The sheet never changes — only the window does.
Three real PDFs (printed out of Chrome, the way most documents reach a browser) went through the live tool with the 0.5" preset. All three came back 26.8% to 43.6% smaller — and so did a control run where I pressed Reset instead, i.e. a crop that changes nothing visible. The size drop is pdf-lib rewriting the document, not the crop.
| Test file | Pages | Input | After 0.5" crop | Change |
|---|---|---|---|---|
| Text, 4 pages (Chrome print) | 4 | 67,381 B | 42,135 B | −25,246 B (−37.5%) |
| Report with tables, 6 pages | 6 | 85,816 B | 48,435 B | −37,381 B (−43.6%) |
| Photo pages, 2 pages | 2 | 49,033 B | 35,875 B | −13,158 B (−26.8%) |
| Control: same text file, box reset to full page (no visible change) | 4 | 67,381 B | 42,131 B | −25,250 B (−37.5%) |
| Files that were already written by pdf-lib | 1–12 | 896–3,651 B | 908–3,666 B | +12 to +20 B (+0.4% to +2.0%) |
The fourth row is the one that matters: cropping nothing removed 25,250 bytes, and cropping a half-inch border removed 25,246 — four bytes fewer. A second session re-ran the same two cases and got 42,138 B cropped against 42,136 B controlled, so the gap between "cropped" and "cropped nothing" is 2–4 bytes while the re-save itself accounts for about 25,000. The saving is the tool re-serialising the PDF (unpacking Chrome's object streams and rebuilding the cross-reference table), not the margin going away: even a byte-for-byte identical operation lands a few bytes apart between sessions because the embedded modification timestamp changes length. On a file pdf-lib wrote itself there is nothing left to unpack, so the same crop adds 12–20 bytes.
Read the box back out of an output and you get [36, 36, 524, 770] on a 596 × 842 page — Chrome prints A4 at 595.28 pt and pdf-lib rounds it up — or [36, 36, 523, 770] on a page pdf-lib wrote itself. Either way the visible width is exactly page width − 72, because 0.5 inch is 36 points on each side. Nothing is re-rendered, which is why a 12-page crop finishes in about half a second.
Not on purpose. The byte change depends on how the original was built, and it can go either way — 43.6% off one file, +20 bytes on another. When a form demands a maximum size, crop for the look and then run Compress PDF, which downsamples images deliberately and can hit a target size you choose.
What Survives a Crop: Text, Bytes and the Hidden Area
The single most useful thing to understand about this tool: a CropBox changes what a viewer shows, not what the file contains. I proved that on a test page with a header, a body line and a footer.
The fixture was a one-page PDF with three text runs: HEADER STRIP SENSITIVE NAME at y = 812, BODY PARAGRAPH THAT SHOULD SURVIVE at y = 600 and FOOTER STRIP PRINTED BY MISTAKE at y = 16. The 0.5" preset sets the visible window to y 36–806, so the header and footer fall outside it. Then I opened both files at the byte level.
| Layer | Before the crop | After the crop | Verdict |
|---|---|---|---|
| Page content stream (the text itself) | 210 bytes | 210 bytes, byte-identical | Untouched |
| Page dictionary | 385 bytes | 409 bytes | Grew by 24 bytes = the new /CropBox entry |
Header text HEADER STRIP SENSITIVE NAME | Present | Still present in the raw stream | Kept, hidden |
Footer text FOOTER STRIP PRINTED BY MISTAKE | Present | Still present in the raw stream | Kept, hidden |
| Body text, as a viewer extracts it | Full page | Body line only | The viewer obeys the box |
| Total file | 987 B | 1,012 B | +25 B (the dictionary entry) |
So the story has three layers, and almost every wrong expectation about cropping comes from mixing them up:
The bytes keep everything
The header and footer are still sitting in the page stream after export. A crop adds a rectangle; it does not delete, redact or re-encode a single glyph. That is why the file can grow while the page looks smaller.
Viewers obey the box
Chrome, Acrobat, Preview and phone viewers all clip to the CropBox, so the header vanishes from the screen and from print. Text selection also stops at the edge, which is how the three-line page extracted as one visible line.
Text stays selectable and sharp
Because nothing is rasterised, what remains in the window is still real text: searchable, selectable, and vector-crisp at any zoom. Compare that with a screenshot-then-PDF route, which would flatten it.
Anyone can widen it again
Opening the cropped file in an editor and setting the CropBox back to the MediaBox restores the full page — the hidden text included. Cropping is a layout decision, never a security one.
Crop for layout: wasted borders, a shipping label on an A4 sheet, a slide deck you want tighter on a projector. Never crop for confidentiality — a bank statement, an ID card, a customer address. For those you need the data gone from the file, not just outside the window. Cover it before the PDF exists, or use a redaction tool that rewrites the content stream. If you must make the crop permanent on a non-sensitive file, section 11 shows three routes and what each one destroys.
The Four Controls That Decide the Result
Handles, two presets, a page scope and a range field — that is the entire interface. Know what each one does and you cannot crop the wrong thing.
Visual mode puts a rectangle on the rendered page with eight handles — four corners, four edges — plus a move-drag inside the box. The rectangle is clamped to the page, so you can never drag it into empty space outside the sheet. A small label above the box shows the live size in points (523×770 pt), which is the only coordinate readout the tool has: there are no x/y/width/height number fields to type into.
0.5" and 1" presets are absolute
Two buttons, 36 pt and 72 pt, applied evenly to all four edges. Measured: clicking 0.5" twice inside one session leaves exactly the same 524×770 pt box both times — the preset recomputes from the page size, it does not stack on itself.
Reset returns to full page
Reset clears the box back to the whole MediaBox — measured on the 4-page test file, all four pages went back to [0, 0, 596, 842] in one press. Use it when you switch from a scanned document to a slide deck and the old margins no longer fit.
All Pages or This Page
Two pills above the preview. "This Page" crops only the previewed page — navigate first with the ← → buttons. "All Pages" writes the same box to every page; the box itself still comes from the page you were looking at, which is why the next section matters.
Range field
Type 1, 4, 6-9 to crop only those pages; leave it blank for the whole file. Measured on the 4-page file, a range of 3 wrote a CropBox to page 3 only — the other three kept [0, 0, 596, 842].
Type a range that matches no page — 9-99 on a 4-page file, or abc — and the parser returns nothing, so the tool falls back to all pages. Measured: 9-99 cropped pages 1–4 while the range field still showed 9-99. If you meant to leave the file alone, press Reset and export, or make sure at least one number in the field is real.
When the Pages Don't Match the Preview
Three real cases where a single preset goes wrong: uneven margins, mixed page sizes and sideways scans. All three were reproduced on the live tool.
1. Margins that differ page to page
Scanned books and stapled handouts rarely have identical borders on every page. Because each run writes one box, you fix this with stacked runs — pages you leave alone keep the CropBox they already have:
Big pass first
0.5" preset, All Pages. Download. Now the bulk of the document is trimmed.
Re-open the output
Upload the file you just downloaded, not the original. Cropped pages keep their existing box until you touch them.
Fix the outliers
Step to a problem page with ← →, press Reset, then drag your tighter box and crop that page. Press Reset first: on an already-cropped file the preset measures from the current window, so 0.5" again goes 524 → 452 pt wide (measured).
2. Mixed page sizes in one file
One box, measured on one page, is written to all of them. In my mixed test file (A4 + Letter + a 4×6 inch label) every page received the A4 box [36, 36, 523, 770]. On the A4 page that is a clean 0.5-inch border; on the 4×6 label the box is wider and taller than the sheet, so the viewer clips it and the label comes out uncropped. Nothing breaks, but nothing happens either. Crop mixed-size documents in groups: one run for the A4 pages, a second run for the small ones.
3. Sideways scans (/Rotate 90)
A page stored upright but flagged "/Rotate 90" previews as landscape. The preset then computes its numbers from that landscape view — 770 × 523 — and writes them to a 595 × 842 page, so the resulting window is lopsided instead of symmetric (measured box [36, 36, 770, 523]: 36 pt on the left and bottom, 211 pt of the box hanging past the right edge so the right margin collapses to 0, and 283 pt left at the top). The fix takes ten seconds: open the scan in Rotate PDF, turn it upright, then crop that copy. With rotation at 0 the box lands exactly where the preview shows it.
Most crop tools sell an "auto-crop" button. It works by sampling pixel rows to guess where content ends, and it misfires on scanner shadows, desk edges and skewed pages — which is exactly the material people crop. This cropper stays manual on purpose: what you see in the preview is what you get, and no page is ever trimmed by a guess.
Crop, Resize or Compress — Pick the Right One
Three jobs that get mixed up constantly. Only one of them leaves the pixels untouched.
| Operation | What changes in the file | File size | Use it when |
|---|---|---|---|
| Crop | A CropBox is added to each page; MediaBox, text and images stay byte-identical (the file is re-saved, which is what moves the byte count) | Unpredictable: −26.8% to −43.6% on Chrome-printed files, +12 to +20 bytes on files pdf-lib wrote | Borders waste screen or paper space and you want them gone from view |
| Resize / scale | Page size and content transform change; everything is scaled | Depends on the engine | The sheet itself must become A4, Letter or 4×6 and the content should fill it |
| Compress | Images are downsampled and re-encoded; redundant objects are dropped | Drops, often by half or more | The file is too heavy to email, upload or attach |
Two consequences follow from that table, and both surprise people:
Cropping changes the page size a viewer reports, but not the paper in your printer. This one has a subtle answer, so I measured all three layers separately. The MediaBox stays exactly as it was — [0, 0, 596, 842] before and after a 0.5" crop. pdf-lib's own getSize() still says 596 × 842. But pdf.js reports the page as 524 × 770, because the CropBox is the region viewers and libraries draw. And printing the cropped file with A4 paper in the dialog produced an A4 page again. So: the file keeps its original sheet, every JS-based viewer treats the crop as the page size, and the printer still asks you for paper.
That is why "crop it to A4" does not work as a page-size conversion. A 524 × 770 pt page is 7.28 × 10.69 inches — neither A4 nor Letter, so a print driver will scale it to whatever paper you choose, exactly as it would have scaled the uncropped page.
Cropping is not a compression step. The hidden part of the page is still inside the file. A crop does move the byte count — 67,381 B down to 42,135 B in my test — but a run with the box reset to full page moved it by almost the same amount (42,131 B), so the saving is the file being rebuilt, not content being hidden. Reach for Compress PDF when weight is the problem, and crop first so the compression runs on the pages you actually keep.
Rotate first (only if a page is sideways) → crop → compress → merge. Each step is lossless for the next one, and page numbers added afterwards are positioned against the visible box instead of a margin nobody sees. A watermark is the exception — it is positioned from the full sheet — so give the result a second look after cropping (section 12).
Scanned Pages: What Cropping Fixes and What It Can't
Scanner output is the reason most people search for a cropper. Three problems show up again and again — only two of them are cropping problems.
| What you see | Can cropping fix it? | The actual fix |
|---|---|---|
| Thick white border, grey scanner bed edge | Yes — that is exactly what a CropBox hides | 0.5" preset, then nudge one edge if the border is uneven |
| Binding shadow or punch holes along one side | Yes — crop that edge deeper | Drag the left handle inward on the pages that show it |
| Page is tilted a few degrees | No — a crop box is axis-aligned | Re-scan with the sheet against the platen edge, or deskew in a scan app before cropping |
| Text runs off the edge of the sheet | No — content was never captured | Re-scan with a wider margin; cropping cannot invent pixels |
For a stack of scans with the same border, one run is enough: 0.5" preset, All Pages, download. For a book where the left margin grows as you approach the spine, run the good pages first, then re-open the output and fix the leftovers with a range — the writes stack, so you finish with a single file.
Put a dark sheet behind the paper and leave 5 mm of clearance at the edges. Scanners then produce a clean, high-contrast border and a single 0.5" crop removes it on every page — no per-page corrections.
Page Sizes, Margins and Labels in Points
Every box the tool writes is in points (1 point = 1/72 inch). Here is the arithmetic for the sizes people actually crop, so you can sanity-check the preview readout.
| Paper / label | Page size (pt) | 0.5" margin box | 1" margin box |
|---|---|---|---|
| A4 | 595 × 842 | 523 × 770 | 451 × 698 |
| US Letter | 612 × 792 | 540 × 720 | 468 × 648 |
| A5 | 420 × 595 | 348 × 523 | 276 × 451 |
| A6 (postcard) | 298 × 420 | 226 × 348 | 154 × 276 |
| 4×6 in shipping label | 288 × 432 | 216 × 360 | 144 × 288 |
| 3×5 in label | 216 × 360 | 144 × 288 | 72 × 216 |
Marketplace labels (Meesho, Flipkart, Amazon): seller PDFs usually wrap one label per A4 sheet with the label sitting in a corner. Crop to the label, then print with scaling set to Actual size (not "Fit to page") and the paper set to 4×6 — the printer will not rescale what is left, and the barcode keeps its 1/8 inch quiet zone. Cropping never re-encodes the page, so barcode bars stay pixel-crisp.
E-readers: a 6-inch Kindle at 300 ppi shows roughly 1072 × 1448 px. If a PDF page keeps its 1-inch margins you spend about a quarter of the width on white space (144 of 595 pt); cropping to 0.5" recovers 16% more width (451 → 523 pt on A4, measured on the box above), which is often the difference between reading without zooming and pinching on every page.
A 0.5" preset removes 72 points of width and a 1" preset removes 144. A 100 × 100 pt label therefore survives 0.5" (28 × 28 pt left) but not 1": the size readout above the box turns negative — −44 × −44 pt in my run — and pressing Crop refuses with "Invalid crop dimensions." Treat a negative readout as the stop sign, press Reset, and drag the box by hand instead.
The table uses nominal A4 (595 × 842 pt), so 0.5" gives 523. Chrome prints A4 as 595.28 pt wide, the file stores 596, and the preset then writes a 524-wide box. Measured both ways: Chrome-printed A4 → [36, 36, 524, 770], pdf-lib-built A4 → [36, 36, 523, 770]. The difference is one point of rounding from how the file was created, never a bug.
Crop Marks, Bleed and the Boxes Print Shops Use
If the file is going to a printer rather than to a screen, the word "crop" means something different to them. This is the one section to read before sending anything to a press.
A PDF page can carry up to five rectangles. The spec lists them in order of precedence, and only two of them show up in ordinary office files:
| Box | What it means | Common in |
|---|---|---|
| MediaBox | The full physical sheet, printing plate edge to edge. Always present. | Every PDF |
| CropBox | The region a viewer shows and prints. Falls back to the MediaBox when absent. | Scans, ebooks, and this tool's output |
| TrimBox | Where the guillotine cuts — the finished page after trimming. Wins over the CropBox when a print workflow reads it. | Commercial print PDFs |
| BleedBox | The area that must be printed past the trim so a 3 mm shift still leaves white-free edges. | Press-ready artwork |
| ArtBox | Just the placed artwork. Sits between TrimBox and CropBox in the fallback order. | Design exports |
The tool in this guide writes one of them: a CropBox. That is code-verified, not inferred — the export path calls setCropBox and nothing else. Two consequences follow, and they matter only when a third party is reading the file:
Print marks survive the crop
Crop marks and registration marks are drawn outside the trim area. Cropping hides them from your viewer, but the drawing commands are still in the page stream, and a prepress workflow that reads the MediaBox can still place them. Never crop a press file to "remove" the marks — export it again without them.
A printer may ignore your CropBox
If the file already carries a TrimBox (many print houses' own exports do), that box wins over the crop you just made. The page looks right on your screen and comes back wrong from the press. Ask which box the shop's RIP honours before you crop rather than after.
Bleed has to be kept, not trimmed
Artwork with a 3 mm bleed needs those 3 mm to survive. A 0.5" preset here removes 12.7 mm — four times the bleed — so a book cover or a poster should be cropped with the handles at a few millimetres in, not with a preset.
Proofing is a cheap check
Before sending a cropped file anywhere, look at it in two viewers (Acrobat and Chrome is enough). If both show the same window, the crop is understood by the common rendering paths; a mismatch is your warning to re-export from the source layout instead.
Cropping here is a viewing tool. It is perfect for trimming white space out of an ebook, a scan or a report you will read on screen. For anything that gets physically cut, set the trim in the layout application that produced the file, keep the bleed, and skip the crop entirely.
What Cropping Cannot Do
Six limits, all verified against this build — knowing them saves a wasted afternoon.
It is not redaction
Measured: the header text outside the crop was still present in the cropped file's page stream, byte-for-byte. Widen the CropBox in any editor and it is readable again. For a passport scan or a client's bank details, cropping is not enough — cover or remove the data itself before sharing. Section 03 has the byte counts.
It is not a compression step
Any size change comes from re-saving the file, not from the crop: a no-change run lost almost exactly as many bytes as a 0.5" crop (−37.5% on a 67 KB file, 2–4 bytes apart). On files pdf-lib already wrote, the same crop adds 12–20 bytes. Use Compress PDF for a size you can control.
It cannot add a margin
The drag is clamped inside the sheet and only a CropBox is written — there is no path to a page bigger than the original. Need annotation space? That is a page-resize job, not a crop.
It cannot straighten a tilted scan
A crop box is axis-aligned. A 3° tilt survives the crop. Re-scan flat, or deskew before cropping.
One box per run
Every selected page gets the same numbers. Different margins per page, or a document with mixed page sizes, needs the stacked runs in section 05.
It cannot rename the sheet
The MediaBox keeps its original size, so a cropped Letter page still says 612 × 792 inside the file even though viewers draw 540 × 720. If a portal checks the page dimensions, crop alone will not satisfy it.
Making a Crop Permanent: Three Routes
If the hidden area must actually be gone — a confidential header, a size limit that inspects the page, a file going to someone who will poke at it — a CropBox is not enough. Here is what each route really costs.
I ran a cropped test page (1,012 bytes, header and footer hidden outside the box) through two of the three routes and opened the results at the byte level. The numbers below are from that run, not from a blog post.
| Route | Measured result | What you lose | Use when |
|---|---|---|---|
| Rasterise and rebuild | 1,012 B → 45,758 B PNG at 1,048 × 1,540 px → 9,799 B PDF (a re-run gave 45,680 B / 1,047 × 1,539 px / 9,777 B). Page box becomes exactly [0, 0, 524, 770], no /Font object, pdf.js extracts 0 text items. |
Every glyph. Text, links, bookmarks and search all disappear; sharpness is frozen at the resolution you picked (2× = about 144 dpi here). | Confidentiality matters more than the text layer, or the page is a scan anyway |
| Re-export from the source | Not measurable here — it depends on the app that made the PDF. This is the only route that keeps vectors and removes the content. | Nothing, but you need the original .docx, .pptx, .indd or .ai file | You still have the source. Always the right first choice. |
| Print to PDF | Not verified here, and I will not quote a number. My headless run printed a blank page and a windowed run captured Chrome's own viewer text — neither is a real rebuild, so neither is evidence. | Usually bookmarks and links; text normally survives because print re-embeds the glyphs | You have no source file and want to keep text selectable — test it yourself first (below) |
The raster route is the one with hard evidence behind it, so it deserves the detail: about 45.7 KB of PNG for a single page is what roughly 1,048 × 1,540 pixels of white background costs, and the rebuilt PDF dropped to about 9.8 KB only because pdf-lib re-compressed that image. Do that to a 40-page report and you have multiplied the file size while destroying the text — which is why the raster route belongs to confidentiality jobs, not to everyday tidying.
The 30-second test for print-to-PDF
Open the printed output, zoom to where the hidden header used to be, and try to drag-select it. If the text is still there and selectable, the rebuild kept the text layer. If nothing selects, you have an image. Do this before sending the file anywhere.
How to tell which file you are holding
Open it in any editor that exposes page boxes (Acrobat's Crop Pages dialog, or a script that prints the CropBox). If the box can be widened and content returns, it was a CropBox-only file. If widening gains nothing but white, the content was really removed.
Do not trust the thumbnail
Thumbnails and previews render the CropBox, so a crop-only file looks identical to a rebuilt one in a file list. The only reliable check is opening the page and probing the hidden area, as above.
The honest hierarchy
Source re-export > raster rebuild > crop-only, for confidentiality. For layout, the order flips: crop-only is best because it keeps everything intact.
Cropping a bank statement, an ID card or a customer address and emailing it is a data leak with a clean-looking page. The bytes are all still in the file — measured in section 03 — and any editor reopens them in seconds. Cover the data before the PDF is created, or rasterise, or re-export from the source. Cropping is a layout tool, full stop.
After Cropping: The Order That Actually Helps
Cropping changes what is visible, so run it before the tools that place things on a page — then check the one tool that ignores the crop box.
A CropBox moves the page edges inward. Tools that ask the file where the page is get the smaller box; tools that ask for the sheet still get its original size. I checked both on a deliberately lopsided crop — a 300 × 400 pt window at [100, 100] on a 595 × 842 sheet, so the visible centre sits at (250, 300) while the sheet centre stays at (297.5, 421). Add Page Numbers put its "1" at y = 148, exactly 48 pt above the visible bottom edge and centred on the box (x 247 against a centre of 250). Add Watermark kept the sheet centre: baseline y = 421, which is 121 pt above the visible centre, and 48.5 pt of its 250 pt width fell outside the box's right edge. Run the same stamp on a symmetric crop and it anchors at the same x (198 in both runs) and stays inside the page — the two boxes share a centre, so only a lopsided crop breaks it.
| Order | Tool | Why here |
|---|---|---|
| 1 | Rotate PDF | Only needed when a page is flagged sideways — a rotated page crops wrong (see above), so fix rotation first. |
| 2 | Crop PDF (this tool) | Sets the final visible window. Everything after this works inside the box you chose. |
| 3 | Add Page Numbers | Numbers are positioned against the cropped box, so they land in the visible footer instead of in trimmed-off white space. Measured on the lopsided test crop: baseline 48 pt above the visible bottom edge, centred on the box. |
| 4 | Add Watermark | Positioned from the full sheet, not the crop box. A symmetric preset keeps both centres on the same point, so the stamp still lands inside the page (verified on the 0.5" preset, nothing clipped); a lopsided crop left it 121 pt above the visible centre with 48 pt cut off — so check it, or nudge it with the X/Y offsets. |
| 5 | Compress PDF | Compression re-encodes images. Run it last so you are not compressing pages you were about to trim away. |
| 6 | Merge PDF | Merging finished files keeps one consistent margin across the combined document. |
There is no PDF page-resize tool in the AFFLIGO toolbox — only Image Resizer for pictures. If a form insists on A4 or Letter, crop the margins here, then open the file in your browser's print dialog, choose the target paper size with Fit to page and save as PDF. The content stays vector-sharp; only the page box changes.
Method and Corrections
How every number in this guide was produced, and the claims from earlier versions that did not survive re-testing.
Method. Measured on 30 October 2026 against the live AFFLIGO crop tool (crop-pages, the build that writes only a CropBox at 72 pt/inch). Nine fixtures: three printed out of Chrome (4-page text, 6-page report with tables, 2-page photo document), and six built with pdf-lib inside the page (a 12-page vector file, a /Rotate 90 page, a mixed A4 + Letter + 4×6 file, a 100 × 100 pt page, a three-line page with text in the crop strip, and that last file's cropped output for the stacked runs). Every run reported its own input bytes, output bytes, wall-clock time and the page boxes read back with getMediaBox() / getCropBox(). Text and hidden content were checked three ways: pdf.js text extraction, raw stream scanning, and inflating the Flate streams to read the operators directly. Positioning after a crop was measured by running the two decorating tools on a purpose-built lopsided crop and reading the text coordinates back with pdf.js.
| Earlier claim | What re-testing showed |
|---|---|
| "Applying the 0.5" preset a second time shrinks the file again (524 → 452)" | Only true for a file that was already cropped. Clicking the preset twice in one session leaves the box at 524 × 770 both times, because the preset recomputes from the page instead of stacking. The 524 → 452 step happens on re-open (the page now reports 524, so 0.5" gives 452). |
| "Cropping does not change the paper size — a Letter page stays Letter" | Half right. The MediaBox is untouched, but pdf.js and other JS viewers report the CropBox: the cropped A4 page measures 524 × 770, not 596 × 842. Only the printer dialog, which asks you for paper explicitly, still works at the paper size. |
| "−27% to −44% smaller, +14–17 bytes on pdf-lib files" | Re-measured as −26.8% to −43.6% and +12 to +20 bytes. The earlier figures were rounded from a smaller sample. |
| "Out-of-range page numbers are dropped rather than throwing an error" | True, but dangerously incomplete. Dropping every number leaves an empty selection, and the tool then falls back to all pages: a range of 9-99 on a 4-page file cropped pages 1–4. |
| "Cropping hides headers and footers but they stay in the file" | Correct, and now provable: the cropped page's content stream came out 210 bytes, byte-identical, with HEADER STRIP SENSITIVE NAME still inside it. The page dictionary grew 385 → 409 bytes — the CropBox entry. |
| "4 pages in 0.30 s, 12 pages in 0.65 s" | Re-measured across nine fixtures from 1 to 12 pages: 0.13 s to 0.54 s. The old numbers were single samples, not a range. |
| "Cropping cannot make a PDF smaller" | Too strong. A Chrome-printed file genuinely came back 37.5% smaller — but so did a control run that cropped nothing (2–4 bytes apart across two sessions). The saving is the re-save, so the honest statement is "unpredictable, never deliberate". |
| "A page number or a watermark added after cropping stays centred on the cropped page" | Only the page number part holds. On a 300 × 400 pt window at [100, 100], the number landed 48 pt above the visible bottom edge and centred on the box, while the watermark kept the sheet centre (y = 421 against a visible centre of 300) and lost 48.5 pt of its width past the box's right edge. Add the stamp first, or nudge it with the offset fields. |
What is quoted from a source rather than measured. The five page boxes and their fallback order (TrimBox → ArtBox → CropBox → MediaBox) come from the PDF specification, ISO 32000-1, section 14.11.2 on page boundaries. Everything else on this page is either a byte count from my own run or arithmetic on the page sizes in section 08.
What is deliberately not claimed. There is no percentage for "how much smaller will my file get" — the control run proves that number is a property of how the PDF was built, not of the crop. There is no number for the print-to-PDF route, because two attempts in a headless browser produced a blank page and a viewer-UI capture rather than a rebuild, and a test that does not test the thing is worse than no test.
Frequently Asked Questions
Eight questions, and each answer points back to the section where the evidence lives.
3 or 2-3 in the range field. Measured on a 4-page file, a range of 3 wrote a CropBox to page 3 only. One trap: a range that matches nothing, such as 9-99 on a 4-page file, falls back to cropping every page — see section 04./Rotate 90 previews as landscape, so a 0.5" preset wrote a 770 × 523 box onto a 595 × 842 page — clipped, not symmetric. Mixed sizes get that same box too, so crop them in separate runs. Details in section 05.Want to explore more?
Key Takeaways
- Cropping writes a CropBox to each page — measured, the page's content stream came out byte-identical (210 bytes in, 210 bytes out) while the page dictionary grew by 24 bytes
- The hidden area is still in the file, headers and footers included, so a crop is a layout decision and never a redaction
- File size moves for a reason that has nothing to do with cropping: the tool rebuilds the PDF, so Chrome-printed files dropped 26.8–43.6% while a no-change run dropped almost exactly the same amount
- The box is measured on the page you are previewing and reused on every selected page, so mixed-size files need separate runs
- A range that matches no page crops every page —
9-99on a 4-page file trimmed all four - A page flagged
/Rotate 90crops wrong — rotate it upright first, then crop that copy - To make a crop physically permanent you must rebuild the page: rasterising gave a 524 × 770 page and zero extractable text
- Order matters: rotate → crop → page numbers → compress → merge, and re-check a watermark afterwards — it positions from the full sheet, not the crop box
