Splitting a PDF by file size means dividing one document into consecutive parts where each generated PDF's actual byte size is measured against a maximum target between 0.01 and 25 MiB. The Split PDF by Size tool does exactly that: you pick a single PDF up to 25 MiB, enter a target in that range, and the browser copies pages into candidate documents, serializes each one to capture its true byte length, and starts a new part before the candidate would cross your limit. Pages are never reordered, skipped, or duplicated, and the page counts of every generated part always add up to the source page count. Because each candidate is serialized and measured rather than estimated from a proportional slice, copied images, embedded fonts, and serializer overhead are handled honestly. The source file and every generated part remain inside the current browser tab throughout the entire workflow, so the document is never uploaded to a remote server.
How to Split a PDF by File Size in MiB
- Open the Split PDF by Size tool in your browser and choose a non-empty PDF no larger than 25 MiB from your device.
- Enter the maximum generated size per part in the target field, accepting any decimal value from 0.01 to 25 MiB to three decimal places.
- Run the split. The browser copies pages into candidate documents, serializes each one to read its actual bytes, and closes a part before the candidate would cross your target.
- Review the result list. Each part shows its page range and its measured byte size, and any oversized single-page part is labeled so you can spot it before downloading.
- Download the numbered parts one by one. Changing the file or the target revokes earlier download links so an old result cannot be confused with a new one.
The minimum 0.01 MiB target is useful for deterministic testing on tiny documents, while the 25 MiB ceiling matches the tool's bounded local workflow. Decimal entries are accepted to three decimal places, so you can specify 4.750 MiB or 0.025 MiB without rounding surprises. Browser and operating-system download displays may round the same byte count slightly differently, so the tool also shows each generated part size for review.
Split by Size vs Split by Page Count
Splitting by page count gives you a predictable number of pages per file but no guarantee that any file is small enough for your email gateway or upload portal. Splitting by size gives you predictable byte limits but variable page counts, because the tool decides where the next part begins based on measured bytes, not on a fixed count. The right choice depends on the constraint you actually face, and on whether the document's page boundaries align with your size budget.
| Constraint you face | Better approach | Local tool |
|---|---|---|
| Email attachment cap of N MB | Split by file size | Split PDF by Size |
| Portal upload limit of N MB | Split by file size | Split PDF by Size |
| Need exactly two halves of equal length | Split by page count | Split PDF in Half |
| Manual ranges like pages 3 to 7 and 14 to 18 | Extract specific pages | Extract PDF Pages |
| Page boundaries do not matter, content must shrink | Compress the file | Compress PDF to Size |
If your receiver rejects an oversized single-page part, the size split has done its job as far as page boundaries allow, and you should follow up with a dedicated compression workflow rather than retrying with a smaller target. Lowering the target further only makes more parts; it never makes a too-heavy page lighter.
How Measured-Byte Splitting Works
The planner behind Split PDF by Size is deliberately conservative. It treats page order as an unbreakable rule, walks pages in their original sequence, and greedily appends each page to a running candidate part. Before it accepts a candidate, it serializes that candidate as a fresh PDF and reads the actual byte length produced by the serializer. If adding the next page would push the candidate past your target, the candidate is finalized as a part and the next page becomes the start of a new part. The page copying step is grounded in the pdf-lib copyPages API and the byte measurement comes from the pdf-lib save call on the candidate document.
Measuring the real output matters because a copied page is not a copy of a stored byte range. PDF resources such as fonts, color profiles, and image streams can be shared across pages, deduplicated by the serializer, or copied with new overhead, so a single heavy image can bloat one page more than its neighbours. Estimating per-page bytes from the source size would assume that every page consumes an equal fraction of the source, which is rarely true for mixed reports, scanned chapters, and image-heavy portfolios. Serializing each candidate catches that distortion and lets the planner close a part at a real byte boundary rather than a guessed one.
Consider a worked scenario with a six-page PDF and a 3 MiB target. The tool tries pages 1 and 2 together, serializes the candidate, and sees 1.4 MiB, which is under the target, so it keeps going. Adding page 3 produces 2.6 MiB, still under 3 MiB, so the candidate is finalized as pages 1 to 3. Pages 4 alone produce 2.0 MiB and pages 4 and 5 together produce 2.5 MiB, both under the limit, so pages 4 and 5 become part 2. Adding page 6 to that candidate would produce 4.3 MiB, which crosses the target, so the planner finalizes part 2 as pages 4 to 5 and starts a new part with page 6 alone at 1.8 MiB. The page counts shown across all three parts add up to 6, matching the source page count.
What Happens When a Single Page Exceeds the Target
Split PDF by Size cannot divide a single PDF page into visual pieces. If one copied page alone serializes to a PDF larger than your target, that page is preserved in its own part and the download is visibly labeled as exceeding the target. The flag is intentional: hiding the oversize would risk silent data loss and would also create an infinite retry loop where the planner keeps trying to fit a page that cannot fit. A flagged oversized single-page part therefore tells you two useful things at once: the page is still present in the output, and the page is the bottleneck your next step has to address.
If a receiving system rejects a flagged part, the size split has done everything it can at the page-boundary level, and a dedicated compression workflow is the right next step. Compression tools can resize embedded images, downsample raster content, or rewrite streams, and those operations come with their own dependency and quality trade-offs that you should evaluate before running them. Treating size-splitting and compression as separate stages keeps each tool's contract honest: one splits, the other shrinks.
Limits, Units, and Input Requirements
The tool runs inside the browser tab, so the practical ceiling is set by available memory rather than a network quota, but the contract is bounded to keep behavior predictable. The accepted source is a non-empty PDF up to 25 MiB. The target must fall between 0.01 MiB and 25 MiB, with decimal values accepted to three places. One MiB equals 1,048,576 bytes, and the unit is labeled clearly so you do not confuse it with a megabyte of 1,000,000 bytes when comparing against an email gateway or upload portal that quotes limits in MB.
Files that are empty, larger than 25 MiB, encrypted, damaged, mislabeled, or unsupported produce a visible error and the split does not begin. Password protection is not bypassed, because the local workflow has no server fallback to attempt a recovery. Each output is a fresh PDF built by copying the selected source pages, so page boxes, rotation, vector artwork, text, and embedded raster content are retained to the extent supported by the existing copy operation. 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, so any document that depends on those features should be inspected in each part before relying on the result.
Which Local Tool Fits Your Job
| Goal | What you need | Tool |
|---|---|---|
| Stay under an attachment or upload cap | Consecutive parts under a measured byte target | Split PDF by Size |
| Produce equal page-count halves | Two parts with the same number of pages | Split PDF in Half |
| Pull specific pages into one new file | Custom page ranges in a chosen order | Extract PDF Pages |
| Sync two documents page by page | Interleaved page order across two PDFs | Alternate Mix PDF |
| Drop pages from a PDF | Remove selected pages and keep the rest | Delete PDF Pages |
| Reduce content size, not page count | Recompress images and rewrite streams | Compress PDF or Compress PDF to Size |
Every entry above runs entirely in the browser, so the same privacy story holds across the workflow: nothing is uploaded, no account is needed, and the only output is the file you choose to download. Picking the right tool for the job is mostly a matter of naming the constraint you actually face, whether that is a byte limit, a page count, a set of specific page ranges, or content that needs to shrink before it can be sent.
If you're weighing options, How to Split a PDF in Half Vertically covers this in detail.