Yes, you can split a PDF by size without uploading the file by using a browser-based tool that processes the document locally. Split PDF by Size runs entirely inside your current tab: you choose a PDF that lives on your device, enter a maximum size in MiB for each output part, and the tool copies pages into fresh PDFs, serializes each candidate, measures its real byte length, and only keeps a part once the next page would push it past your target. The source bytes and every generated part stay on your machine, nothing is sent to Lizely or to any other server, and there is no account or signup step in the way. That makes the workflow well suited to documents you would not normally hand to a remote service: drafts under NDA, medical or financial records, internal reports, or any PDF where the act of uploading itself is the problem. The same local pipeline also gives the tool a precise answer to the question "how big will each part really be?", because each candidate PDF is serialized and measured before it is offered as a download, instead of being guessed from the source size.
How local PDF splitting works in the browser
When you load Split PDF by Size, the page does not open a network channel for your document. The PDF you select is read by your browser through the standard file input or drag-and-drop, and the page stays responsible for that file from then on. Splitting happens through three short, repeatable steps that the page performs on your machine:
- Copy pages in order. The tool walks the page list from page 1 to the last page and uses the pdf-lib copyPages API to copy each page into a fresh in-memory PDF document.
- Serialize and measure. Each candidate PDF is passed to the pdf-lib save API, which produces an actual byte stream. The tool reads that byte length, not an estimate derived from the source file size, and decides whether the candidate fits inside the target you entered.
- Cut at a page boundary. As soon as adding the next page would push a candidate past your target, the current part is finalized and the next page becomes the first page of a new part. Page order is treated as an unbreakable rule.
Because every candidate is serialized for real, the tool catches the cases where a proportional estimate would mislead you. A page that looks small in the source PDF can grow larger than expected once its fonts, images, and cross-references are copied into a new container; conversely, pages that share resources can come out smaller than a naive share of the source size would suggest. Measuring the bytes is the only honest way to honor a fixed-size target, and it is what keeps the page-count totals across all generated parts exactly equal to the structural page count of your input.
Split a PDF by size locally: the exact steps
- Open Split PDF by Size in your browser and pick a non-empty PDF from your device. The file must be no larger than 25 MiB; files outside that range, encrypted PDFs, damaged files, or files that are mislabeled as PDFs are rejected with a visible error before any splitting begins.
- Enter the maximum generated size per part as a decimal MiB value between 0.01 and 25. The minimum is useful for deterministic testing and tiny documents; the maximum matches the local-file workflow's input ceiling. Up to three decimal places are accepted, so 2.5, 0.75, and 12.125 are all valid targets.
- Run the split. The tool copies pages in order, serializes each candidate, and finalizes parts at page boundaries that stay at or under your target. Each candidate that fits is numbered in the order it was produced.
- Review the oversized single-page warning if it appears. A single page that already exceeds the target on its own is kept in its own part and visibly labeled as exceeding the target, so the page is never silently dropped. If you need every part to sit below a strict ceiling, choose a larger target or compress the source with a dedicated compression workflow before splitting.
- Download each numbered part. The downloads are produced from the serialized byte stream, so the size you see in the browser is the actual file size. Changing the source file or the target revokes older download links, so a slow earlier result cannot replace the current job.
What "by size" actually measures
"By size" in this tool refers to the byte length of each generated PDF, not to a percentage of the source file. The page keeps a running candidate document, serializes it through PDFDocument.save, and reads the resulting byte length to decide whether to keep the part or to close it and start a new one. The candidate is closed at the moment adding the next page would cross the target, which means every multi-page part you download has been measured and accepted; it was not estimated and it was not assumed.
Two consequences follow from that discipline. First, the page counts shown for every part add up to the structural page count of the input PDF, because the tool does not reorder pages, skip pages, or duplicate pages. Second, the sizes you see in the results panel are the actual sizes of the parts you will download; any later rounding in your operating system or browser download list is cosmetic and does not change what is on disk.
When one page is larger than the target
PDF pages are not created equal. A single full-bleed scanned image, an oversized embedded raster, or a page with a heavy vector drawing can serialize to a size larger than the target on its own. The tool handles this without losing data: that page is kept in its own part, the part is flagged as exceeding the target, and the next part begins at the following page. This rule is enforced rather than negotiated, because the alternative would be either to silently drop the oversized page or to retry the part forever trying to make it fit.
If your downstream system cannot accept that flagged one-page part, for example an email gateway with a hard attachment ceiling, your options are to raise the target so the flagged part fits alongside its neighbors, or to run a dedicated compression tool first to bring each page below the limit. The page itself is never divided into visual pieces by this workflow.
Choosing the right target size in MiB
The target field uses mebibytes, where one MiB equals 1,048,576 bytes. Decimal input is accepted to three places, so you can enter values like 2.5 or 0.75. As a single worked example, a target of 5 MiB converts to bytes as follows:
- Formula: target in bytes = target in MiB × 1,048,576
- Substituted: 5 MiB × 1,048,576 bytes per MiB = 5,242,880 bytes
- Result: 5 MiB = 5,242,880 bytes (about 5.24 MB in decimal units, depending on how the downstream system defines a megabyte).
Common targets depend on the receiving system. Email gateways commonly cap attachments near 10 MiB; many form-based uploaders accept up to 25 MiB; and very small targets (such as 0.5 MiB) are useful for testing the workflow or for splitting a short document into many short parts. The minimum of 0.01 MiB is intentionally tiny so you can verify behavior with a small file before committing to a real run.
Other local PDF tools for related tasks
Split PDF by Size is one option in a small family of local tools, each of which solves a slightly different problem. The table below compares the cases where each of them is the right choice; in every case the file stays on your device and the work happens in the browser tab.
| Local tool | Best for | Decision input | Output |
|---|---|---|---|
| Split PDF by Size | Splitting one PDF so each part fits a size ceiling | Maximum bytes per part (MiB) | Numbered PDFs split at page boundaries |
| Split PDF in Half | Equal page counts across all parts | Number of parts | PDFs with the same page count |
| Extract PDF Pages | Hand-picked page ranges in a specific order | Exact page numbers | One PDF containing the chosen pages |
| Split PDF | Splitting by page count or custom ranges | Pages per part or range list | PDFs grouped by your rules |
If your real goal is to shrink the bytes rather than to rearrange them, for example so the original document fits under a single upload limit, start with a dedicated compression tool such as Compress PDF or Compress PDF to Size, and only then split if the result still needs to be broken into parts.
Files the tool cannot process
A short list of inputs is refused up front so the workflow never silently produces a half-correct output. The tool rejects empty PDFs, files larger than 25 MiB, encrypted or password-protected PDFs, damaged files, and files that are mislabeled as PDFs but are not. Password protection is not bypassed; if a PDF is locked, unlock it first with a tool such as Remove PDF Password if you already know the password, then return to Split PDF by Size. Changing the file or the size target also revokes earlier download URLs, and a job identifier ensures a slower earlier operation cannot replace a newer result.
For a deeper look, see Split a PDF in Half on Mac: A Browser-Only Method.
For a deeper look, see Split a PDF for Printing: Page-by-Page or by Range.