Setting a size limit and splitting a PDF into parts under it means dividing one local PDF into consecutive PDF files whose actual byte length stays at or below a MiB target you choose. Split PDF by Size copies pages in original order, serializes each candidate part inside the browser, and measures the resulting bytes — not a proportional slice of the source — so every accepted part fits the cap at the moment it is built. If pages 1 through 4 fit together and adding page 5 would push the candidate over the limit, the first download contains pages 1 through 4 and the next part begins with page 5. Pages are never reordered, skipped, duplicated, or visually split. The entire workflow runs inside the current browser tab, so the source file and the generated parts never leave your device. This approach fits email attachment caps, upload portal thresholds, archive chunking, and any workflow that needs a verified maximum output size rather than a guess from the source file size.
What the Size Limit Controls in This Tool
The size limit you enter is a maximum output target measured in mebibytes (MiB). One MiB equals 1,048,576 bytes — a binary unit, not the slightly smaller decimal megabyte. The tool accepts a target as small as 0.01 MiB and as large as 25 MiB, with decimal input allowed to three places. The 25 MiB ceiling matches the tool's bounded local-file workflow; the 0.01 MiB floor is useful for deterministic testing or for very small documents where you want fine-grained control over how many pages end up in each part.
Entering the target is the only decision the workflow requires after you pick the file. The tool does not ask how many parts you want, where page breaks should fall, or how many pages belong in each download. Those decisions are derived from your target and from the actual byte length of the candidate parts the browser builds and measures.
| Setting | Accepted value |
|---|---|
| Source PDF size | Non-empty, up to 25 MiB |
| Target size unit | Mebibytes (MiB) |
| Target size minimum | 0.01 MiB |
| Target size maximum | 25 MiB |
| Decimal precision | Up to three places |
| One MiB in bytes | 1,048,576 |
Decimal input is accepted, so a target of 4.5 MiB means 4.5 × 1,048,576 = 4,718,592 bytes — the value you type is what the planner compares each serialized candidate against.
How the Tool Decides Where to Break the PDF
The splitting engine uses a greedy, page-by-page append with a real-bytes measurement. It starts with the first page, copies it into a candidate document, serializes that candidate, and checks its byte length. If the candidate is at or under your target, the engine keeps appending the next page in source order and re-measuring. The moment appending another page would push the candidate past the target, the engine finalizes the previous group as one part and starts a fresh candidate with the page that did not fit.
This candidate-measure loop is what makes the output trustworthy for a hard size limit. The decision is based on newly serialized PDF files, not on a proportional estimate from the source file size. PDF resources can be shared across pages, compressed differently, or copied into a new document with different overhead than the source had. Measuring each candidate catches those effects directly. The underlying copy operation is documented in the pdf-lib copyPages API, and the byte-measuring serialization step in the pdf-lib save API.
Because the rule "finalize before the candidate crosses the target" is enforced strictly, the page counts across all parts add up to the structural page count of the input. No page is silently lost, no page appears twice, and the original order is preserved across the numbered downloads.
Set the Limit and Split the PDF
- Open Split PDF by Size in your browser.
- Choose a non-empty PDF from your device. The file must be 25 MiB or smaller; empty, larger-than-25 MiB, encrypted, damaged, or mislabeled files produce a visible error.
- Enter the maximum size per part in MiB. The field accepts decimals to three places, from 0.01 up to 25 MiB.
- Select Split PDF by size. The browser begins copying pages into candidate documents, serializing each one, and measuring its byte length against your target.
- Review the part list as it appears. Each entry shows the page range and the measured size of the generated part.
- If any entry is labeled as exceeding the target, that part contains a single page that was already larger than your limit on its own. It is kept intact so the page is not lost.
- Download each numbered part. The downloads appear in original page order and remain valid until you change the file or the target.
- If you change the file or the target, prior download links are revoked and the job identifier prevents a slower earlier result from replacing a newer one.
Why Output Sizes Are Measured Instead of Estimated
A common shortcut for size-based splitting tools is to divide the source file size by the number of pages and assign each page an equal share of the budget. That shortcut breaks down as soon as a PDF contains mixed content — a mostly-text section followed by a rasterized scan of a hundred pages, for example. The text pages might serialize to a few kilobytes each while the scanned pages serialize to several hundred kilobytes each. An even split would either overflow on the scans or leave most of the target unused on the text pages.
Split PDF by Size avoids that failure mode by serializing each candidate and checking its real bytes. The measurement reflects the overhead of copying pages into a new document, the way embedded fonts are re-included or shared, and any compression differences between the source and the freshly built part. A part that the planner accepts has a generated byte length at or below your target at the moment it is built. This is a measurement of the part you are about to download, not a forecast.
Choosing the Right Target for Your Limit
Match the MiB target to the constraint that triggered the split, with a small safety margin because browsers and operating systems may round the same byte count differently in download displays, and because wrappers such as MIME encoding or HTTP request bodies add their own bytes on top of the PDF.
| Scenario | How to set the target |
|---|---|
| External cap with a strict ceiling (email service, upload portal, API request) | Set the target a safe margin below the stated maximum so wrapper overhead does not push the part over the cap. |
| Archive chunking with no external ceiling | Set the target to whatever MiB ceiling you prefer; the tool enforces it as a hard maximum on every accepted part. |
| Round-trip testing of the split logic | Use the 0.01 MiB minimum for deterministic, small-batch testing of the page-boundary behavior. |
The exact byte value that lands at a receiving system can shift slightly because of how headers, base64 encoding, or transfer wrappers add their own overhead. Planning the target a little below the documented limit is what keeps each part safely inside the constraint after wrapping.
What Stays the Same and What May Shift After Splitting
Split PDF by Size is built around an unbreakable rule: page order is preserved. The first download contains the earliest consecutive pages that fit under the target, the second download contains the next consecutive run, and so on. Page counts across all parts add up exactly to the structural page count of the input.
Each output is a fresh PDF made by copying the selected source pages. Page boxes, rotation, vector artwork, text, and embedded raster content are retained to the extent supported by the existing copy operation. The visual appearance of any given page is not modified by the split itself.
What may not survive cleanly across parts are document-level structures that span the original file. Bookmarks, scripts, attachments, portfolio relationships, named destinations, and cross-part links may not preserve their original semantics after pages are separated, because those structures were attached to the source document as a whole rather than to individual pages. If the file relies on these structures for navigation or interactivity, inspect the parts before relying on them downstream.
When a Size Limit Is Not the Right Fix
Size-limited splitting solves one problem: dividing a single PDF into multiple files that fit under a target. It does not change the bytes inside each page. If the source file is too large because of heavy embedded images, oversized fonts, or uncompressed scans, splitting will produce parts that are individually large but still exceed the limit when a single page is bigger than the target on its own. The tool handles that case by keeping the oversized page as its own part and labeling it as exceeding the target, so nothing is silently lost — but the result is not a file that fits the limit.
For shrinking content rather than redistributing pages, a dedicated compression workflow is the right tool. Compress PDF to Size rebuilds the PDF only when a verified recompression result reaches your target. Use compression when the goal is reducing bytes inside pages; use Split PDF by Size when the goal is keeping every page intact and dividing them into multiple files that fit a cap.
For splitting by page count instead of size, Split PDF divides by an exact page count or custom ranges. For hand-picked page selections, Extract PDF Pages copies chosen pages into a new file in any order you specify.
For a deeper look, see How to Split a PDF Into 2 Parts on Every Page.
For a deeper look, see PDF to Long Image for Printing: Sizing and Limits.