To split a PDF by size, set a target between 0.01 and 25 MiB, choose a local PDF no larger than 25 MiB, and the tool divides it into consecutive parts measured by their actual serialized bytes. The target uses mebibytes (1 MiB = 1,048,576 bytes) so a 5 MiB ceiling means each output must fit within roughly 5,242,880 bytes once the PDF has been serialized. That distinction matters because copied PDF pages carry serializer overhead, may share or duplicate resources, and re-pack at sizes that no proportional formula can predict from the source. Instead of estimating, the tool copies pages into a candidate document, serializes it, and only accepts the part if its real byte length sits at or below the target. Page order is an unbreakable rule: the page counts shown across all parts always sum to the structural page count of the input, and the tool never reorders, skips, duplicates, or visually subdivides a single page. Everything runs in the current browser tab, so the document and its generated parts are never uploaded to a server.
How the MiB Target Interacts With Page Boundaries
The MiB target does not draw lines inside a page. It only decides when a candidate group of pages is full. The tool appends consecutive page indices one at a time, serializes after each addition, and accepts the group as soon as the next page would push the candidate over the target. As soon as a candidate crosses the limit, the previous accepted group is finalized as its own numbered part, and the next part begins with the page that triggered the split.
Consider a 10-page source where pages 1 through 4 fit together under the target but page 5 pushes the candidate past the limit. The first download then contains pages 1 through 4 and the next download begins with page 5. The planner never reshuffles that boundary to produce a tighter fit, and the tool never splits a single PDF page into visual pieces. If a receiving system demands parts of nearly equal weight, the natural variation of page content still produces parts of slightly different page counts and byte sizes, and the tool surfaces the real generated size of each part for review rather than trusting a download dialog's rounding.
Split a PDF by Size in Three Steps
- Choose a non-empty PDF no larger than 25 MiB from your device. Empty files, encrypted files, damaged files, or anything above the 25 MiB input ceiling will surface a visible error rather than silently producing a wrong result.
- Enter the maximum generated size per part from 0.01 to 25 MiB. Decimal input is accepted to three places, so values like 2.5, 10, or 18.75 are valid. The minimum is useful for deterministic testing on very small documents; the maximum matches the bounded local-file workflow.
- Select Split PDF by Size, review any oversized single-page warning, and download each numbered part. The tool shows the generated byte length for every part so you can confirm each one actually fits the target before sending it onward.
What Measured Output Bytes Actually Means
PDF resources can be shared across pages, compressed differently, or copied into a new document with very different overhead. A proportional estimate that says "the source is X MiB over 200 pages, so each page is X/200 MiB" almost always lies, sometimes by a large margin, because pages are not independent blobs. The tool instead copies a candidate range, serializes it through the same code path that produces the download (PDFDocument.save), and measures the real byte count.
That is also why the source file size on disk and the sum of generated part sizes will not match exactly. The summed parts include per-part serializer overhead and any resource duplication that the copy operation introduces, while the source file carries its own cross-page structure. For an honest review, the tool displays each generated part size alongside the download, so you can compare the actual output against the target rather than against the source. The underlying copyPages operation is what determines the page contents of each candidate, and the save operation is what produces the bytes that the size check actually reads.
The Oversized Single-Page Exception
A single page cannot be split by this workflow. If one copied page alone already produces a serialized PDF larger than the target, the page is kept in its own part and the download is visibly labeled as exceeding the target. This is intentional: the alternative would be either to silently drop the page or to enter an infinite retry loop, both of which would be worse than a flagged oversized file.
The practical response is to choose a larger target if you have flexibility, or to run a dedicated compression workflow for the page in question before splitting the rest of the document. Compression, image downscaling, and font optimization are out of scope for this tool; the source contract is explicit that it does not compress images, optimize fonts, or linearize a PDF. Splitting is a page-boundary operation with measured output bytes, not a content-reduction operation, so the two jobs should not be conflated.
Input Limits and Local-Only Processing
| Rule | Value |
|---|---|
| Source PDF size | Up to 25 MiB, non-empty |
| Target size per part | 0.01 to 25 MiB, decimal to three places |
| Unit of measurement | Mebibytes (1 MiB = 1,048,576 bytes) |
| Processing location | Current browser tab only |
| Upload behavior | None; source and generated bytes never leave the device |
| Page order | Preserved; sums of part page counts equal source page count |
| Password protection | Not bypassed; encrypted files surface a visible error |
| Document-level structures | Bookmarks, scripts, attachments, named destinations, and cross-part links may not retain their original semantics |
The local-only behavior extends to download lifecycle: changing the file or the size target revokes prior download URLs, and a job identifier prevents a slower earlier operation from replacing a newer result. Files that are empty, larger than 25 MiB, encrypted, damaged, mislabeled, or unsupported produce a visible error rather than a partial result, so a successful run can be trusted end to end.
Choosing the Right PDF Tool for a Size Problem
| Need | Better fit |
|---|---|
| Split a PDF into two roughly equal pieces by page count | Split PDF in Half |
| Pick specific page ranges yourself, in a custom order | Extract PDF Pages |
| Reduce the actual content size of a heavy PDF | Compress PDF or Compress PDF to Size |
| Drop pages you no longer need from one document | Delete PDF Pages |
| Combine several sources into one PDF | Merge PDF |
For background reading on the same task from a different angle, the size-target workflow for email and upload limits walks through a matching scenario and pairs well with the page-boundary focus here. When the real question is "how do I make the file smaller overall," compression is the right first step, and Split PDF by Size becomes a useful follow-up only after a separate compression pass has reduced the source to a workable size.
For a deeper look, see How to Split One PDF Into Two Half-Page Files.