When people say “just merge PDFs in the browser,” they usually mean “pick a library, wire up a button, and export a file.” I thought about it that way at first too. But once I started building pdfzus, I realized that a browser-based PDF merge is not really a file utility problem. It is a product architecture problem with strong privacy, UX, and boundary-setting implications.
That is why I chose to build pdfzus as a browser-based PDF merge workflow instead of starting with a server-first implementation. I wanted local processing, a cleaner privacy story, and a simpler user experience for common document tasks. But I also had to accept that browser-side PDF processing comes with very real limits, especially around memory, very large files, and edge-case documents.
Why I wanted to revisit “merge PDFs online”
A lot of online PDF tools solve the happy path, but many of them also push users into a tradeoff they did not explicitly choose: upload your files to a third-party server, wait, and hope the workflow is trustworthy enough for sensitive documents.
For a product like pdfzus, that tradeoff mattered. Merging PDFs is often not a casual task. People use it for job applications, contracts, forms, administrative paperwork, study materials, and financial records. In those contexts, “online” should not automatically mean “send everything away.”
That was the first architectural decision I made: if the common workflow is “combine a few documents, reorder them, and download one clean file,” then the browser is not just a delivery channel. It can be the execution environment.
That decision shaped the stack. In the repo, the frontend is a Next.js and React app. The PDF workflow is supported by pdf-lib for PDF manipulation, pdfjs-dist for rendering-related needs, and @dnd-kit/* for drag-and-drop ordering. That combination tells the real story: this is not a thin upload form. It is a client-heavy document workflow.
My contrarian take is simple: browser-side PDF merge is often a better product choice than server-side merge, but only if you are disciplined enough to say no to the workloads it should not own.
The stack I chose and why it made sense
I did not want pdfzus to become a generic document-processing backend hiding behind a pretty interface. I wanted a browser-based PDF merge flow that felt direct: import files, reorder them, merge them, export the result.
The core pieces are straightforward:
-
pdf-libgives me browser-friendly PDF manipulation without forcing a server round trip. -
pdfjs-disthelps support preview and rendering-related interactions that matter in a document UI. -
@dnd-kit/*makes file ordering a first-class interaction instead of a clumsy afterthought. - Next.js and React give me a practical way to build the surrounding product experience.
That stack is not exotic, and that is part of the point. For this kind of tool, novelty is less important than control. I needed libraries that were understandable, composable, and realistic to operate in a browser-based app.
I also needed to be honest about what the product is not. The current service worker in the repo explicitly opts out of offline caching. So even though the product leans heavily on local browser processing, I should not describe it as a full offline-first application. That distinction matters. “Files are processed locally” and “the entire app is offline-first” are not the same claim.
That is one of the easiest mistakes to make in technical product writing: once a product has a strong privacy-friendly architecture, it becomes tempting to overextend the narrative. I try not to do that here.
What works well in a browser-based PDF merge flow
For light-to-medium document workflows, browser-side merging is genuinely strong.
If a user wants to combine a cover letter, resume, and certificates into one file, the browser is a great place to do it. If someone needs to merge a few office PDFs before sending them by email, the browser is a great place to do it. If a user needs drag-and-drop ordering before exporting a final document, the browser is a great place to do it.
That is where pdfzus gets its practical advantage. The workflow is narrow enough to stay understandable:
- Import multiple files
- Reorder them visually
- Merge them into one output
- Optionally compress the final document for sharing
This is also where local processing matters most. For everyday document tasks, avoiding unnecessary uploads is not just a technical implementation detail. It is part of the product value.
Another lesson I learned is that drag-and-drop ordering is not a cosmetic feature. In a merge workflow, ordering is the task. If reordering feels brittle, the whole product feels brittle. That is why using a real drag-and-drop foundation matters more than many developers expect.
Where the browser-side approach stops being elegant
My initial mistake was assuming that moving PDF merging into the browser would simplify everything.
It simplifies infrastructure. It does not simplify the entire problem.
The complexity moves.
Instead of designing upload queues, storage lifecycles, and merge jobs on the backend, I had to think harder about memory pressure, large file behavior, and awkward document edge cases. Browser-side PDF processing works well when the workload is modest and predictable. It gets harder when files are huge, document structures are messy, or users expect the browser to behave like a desktop batch processor.
This is where a lot of “browser-side everything” thinking breaks down.
A browser-based PDF merge is a good abstraction when:
- files are reasonably sized
- the task is mostly combine, order, and export
- privacy matters more than heavy processing breadth
- the user benefits from immediate, local interaction
It is a weaker abstraction when:
- files are very large
- the workflow is heavy batch processing
- documents have edge-case constraints such as encryption
- the product starts drifting toward full document infrastructure rather than focused utilities
That is the real failure lesson from building this kind of flow: local processing is not a universal answer. It is a scoped answer.
The architectural tradeoff I would make again
Even with those constraints, I would still choose a browser-based PDF merge for pdfzus.
Why?
Because the product is strongest when it stays focused on common document work, not when it tries to impersonate an enterprise PDF backend. For a privacy-friendly PDF tool, the combination of local handling, lower backend dependency, and a more direct UI is worth a lot.
It also forces better product discipline. Once you accept that the browser is your execution environment, you become more careful about scope. You stop pretending every use case belongs in version one. You think harder about happy paths, failure states, and what the user actually came to do.
That discipline is valuable. In my experience, it is what keeps a focused utility from turning into a confused platform.
What I would tell other developers building something similar
If you are considering a browser-based PDF merge or any client-side PDF processing workflow, I would start with three questions:
1. Is privacy a real product requirement, or just a nice headline?
If users are handling sensitive documents, local processing is a meaningful architectural choice, not a marketing flourish.
2. Is your workflow narrow enough to stay fast and predictable?
If your core task is “select, order, merge, export,” the browser can be a strong fit. If your workflow is much heavier, be careful.
3. Are you willing to define hard boundaries?
The browser is not the wrong place for PDF processing. It is the wrong place for pretending there are no limits.
My practical recommendation is this: use browser-side merge when you want a privacy-friendly PDF tool for common workflows, but design the product around explicit limits from day one. Be honest about what works well, what degrades under pressure, and what belongs in another architecture entirely.
That is the part I underestimated at the start. I thought the hard decision was choosing between frontend and backend processing. It turned out the harder decision was choosing what not to promise.
And that is probably the most useful lesson I got from building pdfzus.
Conclusion
A browser-based PDF merge is worth building when the goal is not “process every PDF workload imaginable,” but “make a common document task simpler, safer, and easier to trust.”
For pdfzus, that meant building around pdf-lib, pdfjs-dist, @dnd-kit, and a React/Next.js frontend, while staying honest about the boundaries of local browser processing. The result is not a universal PDF engine. It is a focused workflow for people who need to merge PDFs in the browser without unnecessary complexity.
If you are building a similar tool, my advice is simple: treat browser-side processing as a product strategy, not just an implementation trick.
Top comments (0)