A handful of thick scanned reports, each already 40-80MB, that all need to become one file before you send them off — and the browser tab goes quiet for a few seconds, or the tool seems to hang. That pause isn’t a bug and it isn’t the file size limit some other tool would have imposed on you (this one doesn’t have one). It’s your own device doing real work: opening every source file, copying every page, and assembling a new one, all in the memory your browser tab has to work with.

What actually happens when you merge large files

Merge PDF works the same way for a 2-page file as it does for a 2,000-page one: each source file gets read into memory in full, its pages get copied into a new document being built up in memory, and once every file has contributed its pages, that new document gets assembled and handed back to you as a download. There’s no size check, no upload queue, no server-side limit anywhere in that path — the entire operation runs on your device using pdf-lib, a JavaScript PDF library, compiled to run directly in the browser tab you already have open.

That’s also exactly why size matters here in a way it wouldn’t on a tool with a server behind it. A server merging your files has however much RAM its infrastructure was provisioned with, dedicated to that one job. Your browser tab has whatever memory your phone or laptop happens to have free at that moment, shared with every other tab and app currently running. Merging ten small PDFs and merging ten 100MB scanned PDFs are doing the same operation, just at very different memory footprints — and the second one is where you’ll actually feel the difference.

What determines whether it goes smoothly

  • Total page count matters more than file count. Five files at 20 pages each is a much lighter job than two files at 400 pages each, even though the second has fewer files. Every page, across every source file, has to be held and copied.
  • Image-heavy scans are the real weight. A scanned document’s size lives almost entirely in its embedded page images — a 60MB scanned PDF is 60MB because of high-resolution photos of each page, not because of text. Text-heavy PDFs of the same page count are dramatically lighter to merge.
  • Other open tabs compete for the same memory. A dozen other tabs, especially anything media-heavy, are drawing from the same pool your browser has available. Closing tabs you don’t need before a big merge genuinely helps.
  • Older or memory-constrained devices feel it first. A modern laptop with 16GB of RAM will merge a stack of large scans without much drama. An older phone or a Chromebook with much less headroom will hit the ceiling sooner — that’s a property of the device doing the work, not something the tool itself limits.

Is it actually memory, or is something else going on?

Not every stall during a merge is a memory problem, and it’s worth knowing the difference before you start closing tabs and compressing files that were never the issue.

A password-protected or genuinely damaged PDF doesn’t cause a slow freeze — it fails fast. Merge PDF opens each source file as it works through the list, and if one can’t be opened (wrong password, a corrupted download, a file that isn’t really a PDF despite the extension), you get an error message within a second or two, not a hung tab. If a stack of files includes an encrypted one, unlock it first with Unlock PDF — merging can’t read pages it can’t open, the same limitation covered in more detail in How to Merge Multiple PDFs Into One File.

Actual memory pressure looks different: the tab keeps working, nothing errors out, it’s just slow — or, at the extreme, the tab itself eventually crashes or silently reloads with no message at all. If you’re not sure which one you’re looking at, a quick test settles it: merge just the two smallest files from your stack on their own. If that also fails or errors immediately, it’s not memory — something about one specific file is the problem. If the small test merges fine and it’s only the full, large batch that struggles, you’re looking at the real thing this post is about.

What to do if a merge is struggling

If a large merge is taking a long time or the tab feels unresponsive, a few things genuinely help, in order of how easy they are:

  1. Close other tabs and apps first, especially anything with video or a lot of images open — that frees up the memory your browser can give this tab.
  2. On a phone, leave the tab alone until it finishes. Mobile browsers are far more aggressive than desktop ones about reclaiming memory from a tab you’re not actively looking at. Switching over to check a message or another app mid-merge is a good way to get the tab reloaded from scratch, losing whatever progress it had made.
  3. Merge in two smaller batches, then merge the results. Combining files A+B into one file, and C+D into another, then merging those two outputs together, uses meaningfully less peak memory than trying to hold all four originals at once — the same total work gets done in smaller steps.
  4. Compress the largest files first if they’re mostly scanned images. Compress PDF shrinks image-heavy pages before you merge them, which reduces both the memory footprint of the merge itself and the size of the final combined file — worth doing first if a couple of the source files are disproportionately large.
  5. Give it time on a genuinely huge job. Thousands of pages across several very large scans is real computational work wherever it runs. A slow tab that eventually finishes isn’t broken; it’s proportional to the job.

The honest tradeoff

A server-side tool with real infrastructure behind it doesn’t hit this same wall in the same way — it has consistent, provisioned memory regardless of what else is going on, and that’s a genuine advantage for enormous batch jobs. What it trades for that is exactly what running entirely in your browser avoids: your files never have to leave your device to get that consistency. For the overwhelming majority of real merges — a handful of reports, a stack of scanned forms, combining a few chapters into one document — the device in front of you has more than enough headroom, and the tradeoff never comes up at all. It’s really only at the extreme end — many hundreds of megabytes across dozens of image-heavy scans — that the difference becomes something you’d actually notice.

Who this is for

  • Combining several large scanned reports or contracts into one file before filing or sending them.
  • Assembling a big stack of scanned forms or invoices — image-heavy, many pages, needs to become a single document.
  • Merging chapters or sections of a large document where individual pieces are already substantial files.

If your files are already reasonably sized — a handful of a few megabytes each — none of this applies; a merge like that finishes near-instantly regardless of device. This is specifically about the upper end, where total size and page count are genuinely large.