Merging and Splitting Large PDFs: Limits, Encrypted Files, and What Gets Lost

Merging and splitting PDFs looks trivial in a demo with two small files. Real documents aren’t small: legal bundles run to hundreds of megabytes, a scanner batch is 200 colour pages, a payslip run is thousands of pages that all share the same letterhead. This post explains what really limits these operations, how PodPDF’s limits were set, and the less obvious things that go wrong — and how we handle them.

Merge and Split Don’t Render Anything

Converting HTML to PDF means running a browser and laying out every page, which takes real time per page. Merging and splitting are different: the pages already exist. The work is reading the PDF’s internal objects and copying the ones each page needs into a new file. Nothing is drawn, rasterized or recompressed.

So page count is a poor measure of effort. Copying thousands of text pages takes seconds. The real constraints are elsewhere:

• How much data can travel in one request. Instant requests carry the file in the request itself, and API platforms cap request size.
• Memory. A PDF library holds the document’s structure in memory while it works; for dense text documents that is several times the file size.
• The size of what comes out. More on that below.

The Limits, and Why

We tested every limit at every size on the same infrastructure the service runs on, measuring time, memory and output size, and set the limits where every run finished comfortably inside its time and memory budget. The limits:

	Instant request	Background job
Upload size	4 MB in total	150 MB in total
Files in a merge	20	100
Pages processed	500	5000
Files from one split	100	500

The instant limit is set by request size, not pages: 4 MB holds roughly 50 to 150 pages of a typical text document, but only about a dozen colour-scanned pages. Anything bigger uploads straight to storage with a signed URL and runs as a queued job, so the request size stops mattering. The dashboard picks the right path for you based on file size.

The page ceilings exist to keep memory predictable, and the output-count ceiling keeps a single job’s bookkeeping small enough to store and list reliably.

What we measured

A few numbers from those runs, on servers sized like production:

Test	Time	Memory
Split a 5,000-page text PDF into 100 files	2.6 s	674 MB
Split 250 colour-scanned pages (92 MB) page by page	1.7 s	483 MB
Merge 100 scanned files (148 MB in total)	1.3 s	1.7 GB
Merge 100 scanned files (200 MB in total)	1.6 s	2.2 GB

Speed was never the problem. Memory was: merging many files means holding all of them at once, and the 200 MB merge came too close to the ceiling for comfort. That’s why background jobs are capped at 150 MB in total. At the far end, a 60,000-page document ran the server out of memory entirely, which is exactly the kind of failure the page ceilings exist to prevent.

Why Split Output Can Be Bigger Than the Input

Split a scanned 200-page document page by page and the 200 files add up to roughly the size of the original: every page has its own image, and each file carries one.

Split a 300-page payslip run the same way and the total can be many times the original. Every payslip shows the same company logo and uses the same fonts, and the original PDF stores those once. But each output must be a complete, standalone PDF, so every one of the 300 files carries its own copy of the logo and the fonts. In our tests, a small templated document with a shared header image grew by more than 100× when split into single pages.

Two things follow:

1. We estimate the output size before starting. PodPDF walks the resources each output will need and adds them up. If the result would be unreasonably large, the request is refused immediately with OUTPUT_TOO_LARGE rather than failing halfway through.
2. You can choose fewer, larger files. every_n instead of each_page shares the header across several pages per file.

Encrypted PDFs Must Be Refused

Many PDFs are encrypted even though they open without a password: bank statements, government forms, exports from document management systems. The encryption controls permissions like printing and copying, and the content streams are still encrypted inside the file.

A PDF library can be told to ignore the encryption and copy the pages anyway. The result opens without complaint and looks fine at a glance — but the page content was never decrypted, so pages render blank or garbled. For a statement run, that means sending customers empty statements with no error anywhere.

So PodPDF checks every file for encryption and refuses it with PDF_ENCRYPTED, naming the file. In the dashboard the file is flagged the moment you add it. It’s slightly less convenient than silently accepting the file, and much better than silently corrupting it.

Damaged and Truncated Files

An interrupted upload or a half-written export produces a truncated PDF. PDF libraries are forgiving by design, and some truncated files still “open” — with pages missing. In testing we found a five-page file, cut at the wrong point, that loaded as a one-page document without any error.

PodPDF therefore checks that every page and every page’s content stream is actually present, not just that the file parses. Anything missing means INVALID_PDF, with the file name, instead of a quietly shorter document.

What Doesn’t Survive Copying Pages

Merge and split work by copying pages. Anything that lives outside the pages is left behind:

Feature	What happens	Warning
Page content, size, rotation	Kept exactly	—
Links and annotations on a page	Kept	—
Fillable form fields	Shown, but no longer fillable	FORM_FIELDS_NOT_PRESERVED
Bookmarks (outline)	Not carried over	BOOKMARKS_NOT_PRESERVED
Digital signatures	Invalidated — the document changed	SIGNATURE_INVALIDATED

The warnings are returned with the result, in the API response and in the dashboard, so the loss is never silent. If you need to keep a signed document intact, send it as a separate file instead of merging it.

Mixed Page Sizes

Merging an A4 contract with a US Letter appendix and a landscape spreadsheet printout gives you a PDF with all three page sizes, each page exactly as it was. PodPDF doesn’t scale or rotate pages to make them match, because doing so would change documents that may need to stay exact.

Retention

Merged and split files can be downloaded again for 7 days, and uploaded input files are deleted once the job has finished. Download links themselves are valid for an hour; GET /jobs/{job_id}/download and GET /jobs/{job_id}/files/{index}/download always give you a fresh one.

Summary

• Merge and split are limited by request size, memory and output size, not by how many pages there are
• Anything over the instant limit uploads directly and runs as a job
• Split output can be far larger than the input when pages share images or fonts; PodPDF checks before starting
• Encrypted and truncated files are refused rather than turned into blank or missing pages
• Forms, bookmarks and signatures don’t survive, and you’re told when they’re affected

Read the API reference, or try merging and splitting in the dashboard.