Ten PDF Claims We Measured Instead of Repeating Them

By PDF Editing Tools Editorial Team ·August 28, 2026 · Updated September 3, 2026

Most advice about PDFs is repeated rather than tested. Some of it is wrong, and the wrong parts cost real time: an hour spent zipping files that will not shrink, or a document cropped in the belief that cropping removes something.

Everything below was measured directly. The method is described for each so you can reproduce it or disagree with it. Where a result contradicts common advice, the number is the argument.

1. Email attachment limits are 25% smaller than they say

Claim tested: a 24 MB file fits under a 25 MB attachment limit.

Result: it does not.

Email cannot carry raw binary data, so attachments are re-encoded as text for transit. That encoding turns every three bytes into four characters — a fixed 33.3% increase, measured on a 3 MB buffer.

Method: encode a 3,000,000-byte buffer as base64 and compare lengths. The ratio is exact and does not vary with content.

What to do with it: aim for three quarters of any stated limit. A bounce at 24 MB against a 25 MB limit is not a bug — the attachment left as roughly 32 MB. More routes around this are in PDF too large to email.

2. Zipping a PDF saves nothing

Claim tested: compressing a PDF into a ZIP archive makes it meaningfully smaller.

Result: it made the file larger, by a fraction of a percent.

Method: a three-page PDF whose page images are incompressible data, then deflate at level 9. Incompressible data is the honest stand-in for the JPEG-compressed images inside a real scan — using ordinary photographic content would have flattered the result, because a first pass would still find redundancy.

Why: PDF compresses its own streams and images as part of the format. Zipping compresses data that is already compressed, and there is nothing left to remove. ZIP remains useful for bundling several files into one attachment; it is not a size reduction.

3. Cropping does not reduce file size — it increases it

Claim tested: cropping away margins makes a PDF smaller.

Result: the file grew by 135 bytes.

Method: set a CropBox one inch inside each edge on every page and save. The increase is the cost of writing the new box entries.

Why: cropping changes which region of a page is displayed. The content outside it is still in the file and returns the moment anyone widens the crop. This has a second consequence that matters more than file size: cropping is not redaction, and a sensitive figure cropped out of a margin still travels with the document. See how to crop PDF margins.

4. Scanning at 600 DPI in colour costs twelve times as much as 300 DPI greyscale

Claim tested: higher scanner settings are worth having “just in case”.

Result: for a page of black text on white paper, twelve times the data describing nothing extra.

Method: pixel count multiplied by channels per pixel — 8.5 × 11 inches at each resolution, one channel for greyscale and three for colour. Resolution doubles in two dimensions at once, so doubling DPI quadruples the data; colour then triples it again.

What to do with it: 300 DPI greyscale is the working default for documents. It is above the threshold where text stays crisp and recognition stays reliable. Going lower is a false economy — at 150 DPI, character shapes lose the detail that separates similar letters. Both directions are covered in how to scan and file paper records.

5. A4 printed on Letter loses 6% of its size, or its bottom edge

Claim tested: A4 and US Letter are close enough not to matter.

Result: A4 is 50 points taller, which is 17.6 mm. Fitting it to Letter scales the page to 94.1%.

Method: the two page sizes in PDF points, at 72 points to the inch.

Why it matters: your printer resolves the mismatch silently, either by scaling everything to 94% — a real problem on anything where measured size carries meaning — or by clipping the bottom. Letter printed on A4 clips the right edge instead. This is the most common cause of a printout that disagrees with the screen: why won’t my PDF print correctly.

6. Rebuilding a PDF drops its document properties

Claim tested: metadata such as the author field survives ordinary page operations.

Result: it does not survive a rebuild.

Method: create a document with title, author, subject, and creator set, then put it through two different operations and read the fields back after each. The rebuild path copies its pages into a fresh document; the rotate path sets a rotation on the existing pages and saves. The first returns empty fields, the second returns all three unchanged.

Why it matters both ways: the author field is filled in automatically by most software from your computer account — frequently your real name. Any operation that rebuilds a document therefore drops it: merging, splitting, extracting, and reordering all do. Rotation does not — it edits the pages in place instead of rebuilding, and a rotated file keeps its title, author, and subject intact. We measured both paths side by side. That makes the drop a useful side effect and not a metadata-removal guarantee, in two separate ways: it does not happen at all when you only rotate, and even when it does happen it does not touch EXIF data inside embedded images, which is where phone photographs carry GPS coordinates. The full picture is in what hidden data your PDF carries.

7. A PDF cannot carry its own bookmarks through a rebuild

Claim tested: page operations preserve a document’s outline pane.

Result: they cannot, and the reason is structural rather than a setting.

Method: search the PDF library used by these tools for any handling of the outline structure. The only matches are an unrelated viewer-preference value; there is no code that reads or writes a document outline at all.

Why it matters: merging, splitting, extracting, and reordering all rebuild a document from its pages, and a rebuild carries what the library understands. Rotation is the exception — it changes an attribute on each page rather than rebuilding, so it is the one operation in this list that leaves an outline where it found it. Page content, size, and orientation come through faithfully. Bookmarks are not dropped by choice — there is nothing in the rebuild that knows they existed.

On a scanned batch this costs nothing, because scans have no outline. On a long reference document that people navigate by its side panel, it is the most disruptive thing any of these operations does — and worth knowing before rather than after. The same applies to digital signatures, which are invalidated by any change by design.

8. Rotating a page costs 34 bytes, not a re-encode

Claim tested: rotating a PDF re-renders its pages, so it costs both quality and file size.

Result: rotating every page of a 4 MB scan changed the file by 34 bytes.

Method: open the scan and read each page’s stored rotation, which is 0, 0, 0. Set all three to 90°, save with the same options these tools use, then reopen the result and read the rotation back. It returns 90, 90, 90 — the check that matters, because a measurement showing “no change” is worthless if the edit never applied. The middle row is the control: opening and re-saving without touching anything costs 12 bytes, so rotation itself accounts for the remaining 22.

Why it matters: a rotation is stored as one number on each page, not as new pixels. The image data is never decoded, so there is nothing to re-compress and nothing to lose — you can rotate the same file a hundred times and get the same picture back. That is why rotating pages is safe to do before cropping or OCR rather than after.

9. Splitting a scanned PDF into single pages costs 0.03%

Claim tested: splitting duplicates whatever the pages share, so the parts add up to noticeably more than the whole.

Result: they add up to 1,158 bytes more, on a file of four megabytes.

Deletion is the same story from the other side. Removing the third page left 2,676,745 bytes, freeing 1,337,199 — within 577 bytes of what that page weighed as a file on its own.

Method: rebuild the document three times, once per page, using the same copy-pages operation the tools use, and add up the results. Then rebuild it once without the third page and compare against that page’s standalone size.

What this does not show: the test document is a scan, and every page of a scan owns its image and shares nothing with its neighbours. The case where splitting should genuinely cost something is a text document whose pages all reference one embedded font, because each output file would then need its own copy. That was not measured here, and this result should not be stretched to cover it.

10. Text added by these tools uses a font that is not inside the file

Claim tested: text added to a PDF is embedded in it, so it looks the same everywhere.

Result: adding one line cost 606 bytes, and the font travelled as a name rather than as a font.

Method: add one line of text with this site’s own function, save, then reopen and save again with object streams turned off so the dictionaries are readable as plain text, and search for font entries. The first attempt searched the compressed output, found nothing, and appeared to prove the font was absent — it proved only that the probe was blind. The control is the same search run against the original scan, which contains no fonts at all: the entries above therefore came from the tool and not from the document.

Why it matters: Helvetica is one of the fourteen fonts every PDF viewer is required to supply, so the text always renders and never shifts position — the character widths are fixed by the file itself. What changes is the shape of the letters, because each viewer substitutes its own: Arial on Windows, Nimbus Sans on many Linux systems. For a date, a set of initials, or a form entry that is a good trade, and it is why the line cost 606 bytes rather than the several hundred kilobytes a real embedded font would add. Where the exact typeface matters, it is a genuine limit, and it is the same substitution described in why a PDF looks different on another computer.

Where the format itself is documented

None of the above is a quirk of one implementation. Page boundary boxes, stream compression filters, the document information dictionary, and incremental saving are all specified in ISO 32000-2, the standard behind PDF. The PDF Association publishes accessible reference material on what that standard covers.

Reading the specification explains most of these results in advance. A PDF arrives already compressed because the format compresses its own streams, so zipping finds nothing. Cropping changes a box rather than the content, so the bytes stay. The measurements confirm the specification rather than contradicting it — which is the useful part, because it means the same reasoning predicts cases we have not measured.

How these were produced

Every measurement above was run against the same PDF library this site’s tools use. The first seven used ordinary generated documents rather than cherry-picked files; the last three used a real three-page scan of about four megabytes, because the questions they ask are about what page operations do to image data. Where a first attempt produced a result that was too good to be true, it was rerun rather than published — the ZIP test is the clearest example: an initial run using formula-generated page content reported a 97.5% saving, which said more about the test data being trivially compressible than about zipping PDFs. Re-run with incompressible content, the honest answer was zero.

Two principles behind all of it:

A measurement needs a sanity check. Several early attempts here failed one — searching a PDF’s raw bytes for text that was in the file did not find it, because content streams are compressed and metadata is stored as UTF-16. A test that cannot detect a thing that is definitely present cannot prove that thing is absent, and a result from a broken test is worse than no result.

Numbers beat adjectives. “Cropping does not save much space” invites argument. “Cropping added 135 bytes” ends it.

If you reproduce any of these and get a different answer, the method above is deliberately complete enough to check where we diverge.

Open Compress PDF