Reddit threads about splitting PDFs by size almost always end with the same advice: keep the file in your browser and use a tool that measures each part's real bytes, not a guess based on the source size. Split PDF by Size does exactly that. It runs entirely in the current browser tab, copies pages from your local PDF into candidate documents, and serializes each one to check its actual length before accepting it as a part. You set a target between 0.01 and 25 MiB, and the tool starts a new part before the next page would push the current one over that target. Page order is treated as unbreakable, so parts contain consecutive pages in the original order and their page counts always add up to the source total. The source file and generated parts never leave the browser, which means there is nothing to upload, register for, or trust a third party with. That is the local, privacy-respecting approach Reddit threads consistently recommend, and it is the foundation everything else in this article builds on.
Why Reddit Threads Keep Recommending Local PDF Splitters
Reddit's r/PDF, r/privacy, and r/sysadmin communities have spent years arriving at the same checklist for PDF tools: keep the file local, do not require an account, do not silently upload to a server, and do not lean on estimates when the tool can measure instead. When someone posts a thread along the lines of "best way to split a 200 MB PDF for email," the top replies almost always point to a browser-based splitter rather than a desktop install or a cloud service.
The reasons are consistent and worth spelling out:
- Privacy. A legal contract, a medical export, or a financial statement should not touch a third-party server when there is a local alternative that produces the same output.
- Speed. Large PDFs upload slowly on many home and mobile connections. Local processing skips the upload entirely.
- Cost. A recurring subscription makes little sense for a task many users run a handful of times a year.
- Portability. A browser-based tool works on a work laptop, a school Chromebook, or a borrowed computer without installing anything.
Split PDF by Size hits every point on that checklist. It runs in any modern browser, accepts a single PDF up to 25 MiB, and uses a measured-bytes approach instead of a rough proportion from the source file size.
What "Split by Size" Actually Measures
Most "split by file size" tools on the web divide the source file size by the number of parts and call it a day. That estimate is wrong in both directions. A PDF page with one large embedded image can weigh far more than a page with a single paragraph of text, and copied PDF resources can be shared across pages, compressed differently, or wrapped with new serializer overhead when they are copied into a fresh document.
The tool avoids that trap. The browser copies pages into a candidate document, calls the PDF serializer, and measures the actual byte length of that candidate. The next page is only added when the new serialized length stays at or below the target. When adding the next page would push the candidate over the target, the previous group is finalized as a part and the next page becomes the seed of a new one.
The result is honest: each accepted multi-page part has a real byte length at or below the chosen target at the time it was built. The tool also displays each generated part's size on the results screen, so you can review the measurements before downloading. Because browser and operating-system download displays can round the same byte count differently, that on-screen value is the one to trust.
How to Split a PDF by Size in Your Browser
- Open Split PDF by Size in any modern browser.
- Choose a non-empty PDF from your device that is no larger than 25 MiB.
- Enter the maximum generated size per part as a decimal value between 0.01 and 25 MiB (for example, 5 or 4.75).
- Click the Split PDF by size button.
- Read any oversized single-page warning the tool surfaces and decide whether to keep going or adjust your target.
- Download each numbered part in order. The page counts of all parts will add up to the source page count.
If your input is empty, larger than 25 MiB, encrypted, damaged, mislabeled, or unsupported, the tool surfaces a visible error and stops before any download links are issued. Password protection is not bypassed.
MiB vs MB and the 0.01 to 25 Target Range
The target uses mebibytes, where 1 MiB equals exactly 1,048,576 bytes. That is the binary multiple defined by the International Electrotechnical Commission and the unit most operating systems and email gateways use when they report a file size in MiB. Decimal megabytes (1 MB = 1,000,000 bytes) are a different unit, and a target described as "5 MB" in one system can mean a different byte count in another. Using MiB keeps the math honest.
The tool accepts decimal input to three places, so 0.01 MiB works for deterministic tests on tiny documents and 25 MiB matches the local-file size cap. The minimum is useful for very small documents and testing; the maximum mirrors the bounded local-file workflow.
| Target | Bytes | Decimal MB equivalent |
|---|---|---|
| 0.01 MiB | 10,486 | 0.01049 MB |
| 0.1 MiB | 104,858 | 0.10486 MB |
| 1 MiB | 1,048,576 | 1.04858 MB |
| 5 MiB | 5,242,880 | 5.24288 MB |
| 10 MiB | 10,485,760 | 10.48576 MB |
| 25 MiB | 26,214,400 | 26.21440 MB |
Because browser and operating-system download displays can round the same byte count in different directions, the tool also shows each generated part size next to its download link for independent review.
When One Page Already Exceeds the Target
A single PDF page cannot be split into smaller visual pieces by this workflow, and the tool will not pretend it can. If copying a single page already produces a PDF larger than your target, that page is kept as its own one-page part and the download is visibly labeled as exceeding the target.
That exception exists for three reasons worth naming:
- It prevents silent page loss, since the page still appears in the output, just inside a flagged file.
- It prevents infinite retry loops, because there is no smaller page slice to fall back to.
- It tells the truth: a flagged oversized single page is more useful to the reader than a missing one.
If a downstream system rejects the flagged oversized part, the practical choices are to raise the target so the flagged file fits, or run a dedicated compression workflow on the source first and then re-split.
Pick the Right Lizely Tool for the Job
Split PDF by Size is built around one question: how many bytes should each part be? When the real question is different, a different tool serves better.
| Your real goal | Best fit |
|---|---|
| Cap each part at a maximum serialized byte count | Split PDF by Size |
| Split into equal page counts | Split PDF in Half |
| Pull a custom range of pages into a new file | Extract PDF Pages |
| Split into N roughly equal page counts | Split PDF |
| Shrink the source's total byte count | Compress PDF |
None of these tools upload the file. All of them run in the current browser tab the same way, so the choice is purely about which one matches the task you actually need to do.
How the Tool Works Under the Hood
The implementation is straightforward and worth describing because it is what makes the measurements honest. The browser validates one bounded PDF and the decimal MiB target you entered, then walks the page list in order. It appends each page index to a candidate document and serializes that candidate after every append so the real byte length can be read. If the next page would push the candidate over the target, the previous candidate is finalized as a numbered part and the page that broke the limit becomes the seed of the next candidate. An oversized single page is preserved as its own flagged one-page part instead of being retried, and numbered download links are exposed once the entire walk is complete.
The serializer used for measurement is the same serializer used for the final download, so the byte length you see in the results is the byte length you receive. The methodology maps directly onto the pdf-lib copyPages API and the pdf-lib save API, which are the public interfaces the workflow relies on.
Page boxes, rotation, vector artwork, text, and embedded raster content are retained to the extent the existing copy operation supports. Advanced document-level structures such as bookmarks, scripts, attachments, portfolio relationships, named destinations, and cross-part links may not preserve their original semantics once pages are split across files, so interactive documents should be inspected before relying on the parts. Changing the file or the size target revokes earlier download URLs, and each run is keyed by a fresh job identifier so a slower earlier operation cannot replace a newer result on the same tab.
Sources and Further Reading
The two underlying APIs the tool is built on are documented at pdf-lib API — PDFDocument copyPages and pdf-lib API — PDFDocument save. For a deeper walkthrough of the same measured-bytes approach described here, see the Lizely guide Split a PDF by Size: A Local Browser Method, which expands on the local-processing rationale that Reddit threads keep surfacing.
Related reading: Split a PDF in Half: Scans, Spreads, and Two-Panel Layouts.