Split a PDF by File Size: Why the Parts Never Add Up (and the 37% Email Tax)

"Split this 60 MB PDF into parts under 20 MB" sounds like division: three parts, every 20 pages, done. Then part 2 comes out at 26 MB and bounces. Size-based PDF splitting goes wrong for two independent reasons. The PDF format doesn't let page sizes add up, and the limit you're targeting usually isn't measured the way you think. This guide covers both, and the method that gets it right first time.

#Reason 1: PDF parts don't add up

A PDF isn't a stack of pages laid end to end. It's a graph of objects (page dictionaries, content streams, fonts, images, colour profiles) connected by references. A font used on all 200 pages is stored once, and each page points to it. A logo on every page header is one image object referenced 200 times.

Splitting has to make each part self-contained, so every shared object a part's pages touch gets copied into that part. That has predictable effects:

• Shared fonts are duplicated. A report set in an embedded font family pays for those fonts once per part. Embedded subsets for a few weights can easily run to hundreds of kilobytes, which matters when you split into many small parts.
• Repeated images are duplicated. A letterhead or watermark image is stored once per part instead of once per file.
• Per-part overhead. Every part needs its own catalog, page tree and cross-reference data. It's small, but it isn't zero.

So the parts usually sum to more than the original, and the excess is concentrated in parts whose pages share heavy resources.

#…except when they sum to less

The opposite also happens, and it surprises people. Many editors (Acrobat included) save changes incrementally: instead of rewriting the file, they append the changed objects and a new cross-reference section to the end. The superseded objects stay in the file, unreferenced but still taking up bytes. A contract that went through ten rounds of edits can carry several old versions of the same images.

A splitter that rebuilds each part from only the objects its pages reference drops all of that dead weight. Heavily edited files often split into parts that sum to less than the original. Either way, the size of a part can't be known by arithmetic.

#Page weight is wildly uneven

Even ignoring shared objects, pages differ by orders of magnitude. A text page is a few kilobytes of compressed drawing instructions; a full-page colour scan is 0.5–3 MB of JPEG data. The heavy pages cluster: the appendix of scanned exhibits, the photo section. "Every N pages" puts all of them into the same part.

#Reason 2: the limit is measured after encoding

Email is the most common reason to split by size, and it adds its own distortion. SMTP carries text, so attachments are base64-encoded: every 3 bytes become 4 characters, a 4/3 expansion. MIME then wraps the encoded text at 76 characters per line plus a 2-byte CRLF:

4/3 × 78/76 = 1.368

Mail providers apply their limits to the encoded message, so the largest PDF that fits is the limit ÷ 1.368:

Leave a little extra room for the message body and headers. Upload portals (court e-filing, university submissions, HR systems) usually measure the raw file, so the plain limit applies there. The split.tools splitter makes this a checkbox: email-safe mode targets limit ÷ 1.368, plain mode targets the limit itself. Both treat 1 MB as 1,000,000 bytes, the conservative reading when a provider doesn't say which "megabyte" it means.

#The method that works: measure, don't estimate

Since a part's size can't be predicted, the reliable approach is to build the part and weigh it. Split PDF by Size does this greedily, from the first page forward:

1. Starting from the current page, build a candidate part, save it to bytes, and measure it.
2. If it fits, double the number of pages and try again. If it doesn't, the boundary lies between the last size that fit and the one that didn't.
3. Binary-search that interval for the largest page count that fits, then emit the part and continue from the next page.
4. Start each new part's search at the previous part's length, which is usually close.

Each part costs about log₂(pages) trial saves, and saving a PDF in the browser takes milliseconds per page, so a few hundred pages split in seconds. The result is the minimum number of consecutive parts in which every part is under the limit.

Consecutive is deliberate. A packing algorithm could fit pages into fewer parts by shuffling them, but nobody wants to receive pages 1–20, 45 and 61 as "part 1."

#When a single page is over the limit

No split can go below one page. If one page alone exceeds the limit, the tool puts it in its own part and flags it. That page is almost always a high-resolution scan. A US Letter page scanned at 600 dpi in colour is 5,100 × 6,600 pixels, about 100 MB of raw pixel data before JPEG compression, and still several megabytes after it. Your options:

• Rescan or re-export at 300 dpi. That's a quarter of the pixels, and still more than enough for documents.
• Compress just that page's images, then split again.
• Raise the limit if the recipient allows it, or send that one part as a link.

#Size splitting vs compression vs links

Splitting is the only option that keeps every page byte-faithful and still works with nothing but email. It's also usually what upload portals expect: per-file caps are common, file-count caps less so.

#Naming parts so they survive the inbox

Split parts get separated: forwarded individually, saved into different folders, attached out of order. Name them with both their position and their page range (report_part02_p35-61.pdf) so anyone can tell what's missing. Put "Part 2 of 4" in the email subject as well.

Split your PDF by size in the browser: each part is measured before you download it, and the document never passes through a server on its way to the inbox.