Most Split PDF tools divide documents by page count. Tell the tool to split every 10 pages, and it produces a set of 10-page chunks regardless of how much data each page contains. For documents where page content density varies widely, page-count splitting produces files of wildly different sizes. A 10-page section of text might be 100 KB. A 10-page section with high-resolution photographs might be 25 MB. Splitting by file size instead of page count produces output files that are each under a specific megabyte limit, which is what email servers, upload forms, and document management systems actually enforce.
File-size-based splitting is more complex than page-count splitting because the tool must estimate how many pages fit within the target size before performing the split. The estimation is never exact because PDF compression and object deduplication affect the final file size. The tool splits conservatively, producing files slightly under the target, and the last file contains whatever pages remain.
WukongPDF's PDF Batch splitting tools provide both page-count and file-size split options for document distribution workflows.
Why File-Size Splitting Matters for Distribution
Email attachment limits are the most common reason for file-size splitting. Gmail limits attachments to 25 MB. Outlook limits to 20 MB for most plans. Corporate email servers often impose even lower limits, sometimes 10 MB or 5 MB. A 60 MB PDF that needs to be emailed must be split into chunks that fit under the recipient's attachment limit. Splitting by page count might produce one chunk at 22 MB and another at 38 MB, neither of which can be emailed. Splitting by file size guarantees every chunk is under the limit.
Online upload forms also enforce file size limits. Government portals, court filing systems, and job application sites commonly limit uploads to 5 MB, 10 MB, or 25 MB. The limit is displayed on the upload page, and exceeding it produces an error after the upload has already consumed time. Pre-splitting the PDF into size-compliant chunks ensures the upload succeeds on the first attempt.
Document management systems with per-file storage quotas benefit from consistent file sizes. A system that charges by stored gigabyte is indifferent to whether files are split by page count or by size, but a system that limits the number of files per record may penalize page-count splitting that produces many small files. Understanding the downstream system constraints informs the splitting strategy.
Method 1: Adobe Acrobat Pro's Split by Size
Acrobat Pro includes a file-size split option in its Split Document tool. Open the PDF and go to Tools, Organize Pages, then click Split. In the split dialog, choose File Size from the split-by dropdown. Enter the maximum file size in megabytes. Acrobat estimates how many pages fit within that size and splits accordingly.
The Acrobat split-by-size algorithm works well for documents with relatively uniform pages. For documents with highly variable page sizes, the estimate may be off by 10 to 20 percent because Acrobat cannot precisely predict how much the output compression will reduce each page's contribution to the file size. After splitting, check the actual file sizes of the output chunks. If any chunk exceeds the target, reduce the target size slightly and re-split.
Acrobat names the output files by appending a suffix to the original filename, such as Document_Part1.pdf, Document_Part2.pdf. The naming convention makes it clear that the files are parts of a whole and indicates the correct reading order. For documents that will be recombined by the recipient, include a cover page in the first part explaining how many parts to expect and how to reassemble them.
Method 2: Command-Line Splitting With pdftk
pdftk does not have a native split-by-size feature, but it can be scripted to achieve the same result. The approach is to split the PDF into individual pages, measure each page's file size, and then group pages into chunks whose cumulative size stays under the target. A bash or PowerShell script automates this workflow.
First, use pdftk to burst the PDF into individual page files: pdftk input.pdf burst. This produces pg_0001.pdf, pg_0002.pdf, and so on. Use a system command like ls -l or du to measure each page file size. Iterate through the pages in order, accumulating sizes until the next page would push the total over the target. When the target is reached, merge the accumulated pages into a chunk file using pdftk cat, reset the accumulator, and continue with the next chunk.
In practice, the pdftk approach is free and scriptable, making it suitable for batch processing and server-side automation. The accuracy depends on the per-page file size measurement. Individual pages measured as separate files may be slightly larger than the same pages combined into a single PDF due to shared resources like fonts being duplicated across the individual page files. The final chunk file sizes will be somewhat smaller than the sum of individual page sizes.
Method 3: Python Scripting With pikepdf
In practice, the pikepdf library provides programmatic control over PDF splitting with byte-level precision. A Python script opens the PDF, iterates through pages, and uses the pikepdf API to create a new PDF for each chunk. The script tracks the cumulative uncompressed size of the pages added to the current chunk and starts a new chunk when adding the next page would exceed the target.
pikepdf provides access to the raw page content streams, enabling accurate size estimation before the output file is written. The script can also compress each chunk with specific settings, such as JPEG compression for images, to further control output file size. The Python approach handles edge cases like a single page that is larger than the target size by compressing that page individually rather than failing.
Handling Edge Cases in File-Size Splitting
When a single page exceeds the target file size, the split cannot produce a chunk containing only that page while staying under the target. Options include compressing the oversized page individually with more aggressive image downsampling, splitting the page into smaller sub-pages if the page consists of multiple logical sections, or accepting that this page will exceed the target and noting the exception.
For documents with many small pages, the split-by-size algorithm may produce chunks with very different page counts. Chunk 1 might contain 50 pages of text. Chunk 2 might contain 3 pages of photographs. The recipient should be informed that the chunks vary in page count because the split criterion is file size, not page count.
| Method | How It Works | Best For |
|---|---|---|
| Acrobat Pro Split by Size | Specify max MB per output file | GUI users, occasional splits |
| pdftk with size estimation | Iterate pages until target size reached | Scripted workflows, free |
| Python + pikepdf | Read page sizes, split when cumulative exceeds target | Custom logic, batch processing |
Verifying Split Output Before Distribution
After splitting by file size, open each output chunk and confirm that the first and last pages are correct. The split should occur at page boundaries, not in the middle of a page. Verify that the total page count across all chunks equals the page count of the original document. A discrepancy indicates that a page was dropped during the split.
Check the file size of each chunk against the target. Chunks should be at or slightly below the target. If a chunk exceeds the target by more than 5 percent, the split algorithm underestimated the output size. Reduce the target by 10 percent and re-split. The 5 to 10 percent margin accounts for compression variability and shared resource overhead.
Splitting a PDF by file size instead of page count produces output that respects the real constraints of digital distribution. Email servers, upload forms, and storage quotas do not care how many pages a PDF has. They care how many megabytes it is. File-size splitting aligns the split strategy with the constraint that matters.
Automating Recurring File-Size Splits
From a practical perspective, in document workflows, for organizations that regularly split large PDFs for distribution, automate the split-by-size workflow. A script monitors a folder for incoming PDFs above a threshold size, splits them into chunks under the organization's standard email attachment limit, and saves the chunks to an output folder with consistent naming. The automation removes the manual split step from the document distribution process.
The automation can also generate a manifest file listing each chunk filename, its file size, and the page range it contains. The manifest accompanies the chunks and tells the recipient how to reassemble the document. A simple text file with one line per chunk and the original filename as the header is sufficient. The manifest turns a collection of arbitrarily named chunk files into a clearly documented document package.
Looking at this broadly, in document workflows, for enterprise document management systems, the split automation can integrate with the system API to register each chunk as a related component of the parent document. The system tracks that the original 60 MB document was split into three 20 MB chunks for distribution and can reassemble them on demand for users who need the complete file.
Reassembling Split Files on the Recipient Side
Typically, the recipient of a file-size-split document needs clear instructions for reassembly. Most PDF merge tools can combine the chunks back into the original document if they are merged in the correct order. The chunk filenames should indicate the order: Document_Part1_of_3.pdf, Document_Part2_of_3.pdf, and so on. The recipient opens a merge tool, adds the files in order, and produces the reassembled document.
For non-technical recipients, include a brief instruction file with the chunks. The instruction file explains what the chunks are, how many there should be, how to recombine them using a free online PDF merge tool, and who to contact if a chunk is missing or corrupted. The extra minute spent writing the instruction file prevents confusion and support requests from recipients who receive multiple PDF attachments without context.
After reassembly, the recipient should verify that the page count of the merged document matches the page count stated in the manifest. A mismatch indicates a missing or duplicated chunk. The manifest page count is the authoritative reference for confirming complete reassembly.