Splitting a PDF by file size means choosing a maximum output size and letting the tool decide where page boundaries fall so each generated part stays at or below that target. With the Split PDF by Size tool, you set a target between 0.01 MiB and 25 MiB — decimal input is accepted to three places — and the browser copies pages one at a time into candidate PDFs, serializes each candidate, measures the actual byte length, and starts a new part before the next page would push the running total over your limit. Because the measurement is taken on freshly serialized files, parts are accepted only when their real bytes are at or under the target. Page order is treated as an unbreakable rule: pages are never reordered, skipped, duplicated, or split into visual pieces, and the page counts shown across all numbered parts always add up to the structural page count of the input.
What "Separate by Size" Actually Means
Most PDF splitters ask for a page count — every 10 pages, every 20 pages — and produce uniformly sized chunks that ignore how heavy each page actually is. Separating by size takes the opposite approach: you declare how many bytes each output may contain, and the tool decides how many pages fit inside that ceiling. A four-page scanned invoice may produce a much larger PDF than a four-page text-only report, and a size-aware tool reflects that asymmetry rather than pretending all pages are equal.
The target you enter is read in mebibytes. One MiB equals 1,048,576 bytes — not one million — and the tool accepts decimal values to three places, so 4.5 MiB or 0.75 MiB are valid targets. The minimum of 0.01 MiB is useful for deterministic testing of very small documents, and the maximum of 25 MiB matches the tool's bounded local-file workflow. Because the target is interpreted strictly in these bytes, you can compare it directly to any recipient's published ceiling without converting between powers of two and powers of ten.
Separation by size is the right method when your goal is fitting a constraint you do not control: an email attachment cap, an upload portal that rejects large files, a chat app that refuses oversize attachments, or an archive quota. It is not the right method when you need exactly N parts, when you already know which pages belong together, or when you want every output to contain the same number of pages regardless of how heavy each page is.
Separate a PDF by Size in Your Browser
The Split PDF by Size tool runs entirely in your current browser tab. Page copying, candidate serialization, byte measurement, and download creation happen locally; the source PDF and the generated parts are never uploaded to Lizely. To separate your document by file size:
- Choose a non-empty PDF no larger than 25 MiB using the file picker. Files that are empty, larger than 25 MiB, encrypted, damaged, mislabeled, or unsupported produce a visible error before any work begins.
- Enter the maximum generated size per part in MiB. Any value from 0.01 to 25 is accepted; use three decimal places when you need fine control (for example, 4.75 MiB).
- Select Split PDF by size. The browser copies pages into a candidate PDF in source order, serializes that candidate to count its actual bytes, and accepts the group as a part when adding the next page would cross the target.
- Review any oversized single-page warning. If one copied page alone produces a PDF larger than the target, that page is kept in its own part and clearly flagged so it cannot be mistaken for a successful split.
- Download each numbered part. The downloads are fresh PDFs made by copying the selected source pages, with the visible size of each generated part shown for review alongside the file.
Changing the source file or the size target revokes prior download URLs so an old result cannot be confused with the current settings, and a job identifier prevents a slower earlier operation from replacing a newer result.
Why the Tool Measures Output Bytes Instead of Estimating
A common shortcut in older tools is to divide the source file size by the number of pages and assume each page consumes an equal fraction. That estimate falls apart quickly. PDF resources can be shared across pages, recompressed differently, or copied into a new document with different overhead. The serializer used here is the same library that produces the final downloads, so measuring each candidate catches those effects more honestly than assuming linearity.
Concretely, a 10 MiB source PDF with 20 pages is not guaranteed to split into two 5 MiB parts under a 5 MiB target. Some pages may be near-empty text and others may be scanned images; copying and serializing them produces uneven byte counts. By serializing each candidate — using the PDFDocument save step — and measuring its real length, the tool accepts a part only when its freshly generated bytes are at or below the target at the time it is built. The page-copying step uses the same library's PDFDocument copyPages behavior, so what you measure is what you download.
Browser and operating-system download displays may round the same byte count differently, which is why the tool also shows each generated part size for review before download.
When One Page Is Larger Than Your Target
A single PDF page cannot be split into visual pieces by this workflow. If a copied page alone produces a PDF larger than the target, the tool keeps that page in its own part and visibly labels it as exceeding the target. This exception is intentional: silently dropping the page would lose content, and retrying with a smaller target would loop forever.
If a receiving system rejects that oversized single-page file, the practical remedies are: raise the target so that page fits alongside one or more neighbors; remove the heavy page with Delete PDF Pages if its content is not essential; or run a dedicated compression workflow against the source. For guidance on whether compressed output is guaranteed to meet a target size, see Will a Compressed PDF Always Meet Your Target Size?
| Situation at the Target | What the Tool Does | Recommended Next Step |
|---|---|---|
| Multi-page candidate fits at or under the target | Accepted as a numbered part | Download as normal |
| Adding the next page crosses the target | Previous group finalized; next part begins with that page | Download as normal |
| A single copied page already exceeds the target | Kept as a flagged one-page part | Raise the target, delete the heavy page, or compress the source |
Picking a Target Size That Fits Your Recipient
The right target depends on where the parts are going. Large webmail providers typically allow attachments close to the tool's 25 MiB input ceiling, while government and benefits upload portals often publish explicit per-file ceilings well below that. Free chat tiers usually cap attachments lower than paid plans, and small archive quotas push you toward the lower bound of the tool's 0.01 MiB minimum. Use these ranges as a starting point, not a guarantee — always check the actual ceiling published by the recipient system and leave a small buffer for metadata differences between your serialized output and what the recipient's parser measures.
For a quick sanity check on the MiB unit: 0.5 MiB equals 0.5 × 1,048,576 bytes, which is 524,288 bytes — exactly 512 KiB. The tool's decimal input is read in these bytes, so a target of 0.5 always means the same ceiling regardless of how your operating system displays the result.
How Separation by Size Compares to Other Methods
| Method | What It Decides | Best For | Key Limitation |
|---|---|---|---|
| Separate by size | Number of pages per part, so byte count stays under a target | Fitting email caps, upload portals, quotas | Cannot split a single page |
| Split by page count | Number of pages per part, regardless of weight | Evenly distributed chunks, predictable part count | Output size varies with page content |
| Manual page ranges | Specific page indices per part | Pulling chapters, removing covers, custom groupings | You must already know the page boundaries |
For equal page counts use Split PDF in Half; for manual ranges use Extract PDF Pages; for reducing content size use a dedicated compression tool after its dependency and quality requirements have been evaluated. Whatever method you choose, advanced document-level structures such as bookmarks, scripts, attachments, portfolio relationships, named destinations, and cross-part links may not preserve their original semantics after pages are separated. Inspect important interactive files before relying on the parts.