That is not the real problem.

When I started shaping pdfzus, I realized the hard part was not “can I merge PDFs?” The hard part was deciding where that merge should happen, what kind of workloads the product should support, and how much of the UX should be constrained by privacy rather than by backend convenience. That is why I chose a browser-based PDF merge architecture first. It gave me a stronger privacy model and a more direct user experience, but it also forced me to be much more honest about limits.

The real question is not “can the browser do it?”

The obvious engineering question is whether the browser can merge PDFs at all. Today, that part is no longer especially controversial. The repo already reflects the building blocks clearly: pdf-lib is present for document manipulation, pdfjs-dist is present for rendering-related tasks, and @dnd-kit/* is present for drag-and-drop interactions. React and Next.js handle the surrounding application structure.

So the browser can do it.

The more important question is whether the browser should do it for your product.

That is where I think a lot of PDF tool discussions go wrong. Developers often reduce the architecture decision to a capability question: “Can I make this work locally?” But for a real product, the better question is: “What complexity am I accepting if I do?”

That distinction mattered pdfzus. I was not trying to build a giant document platform. I wanted a privacy-friendly PDF tool for a narrow but common workflow: import multiple PDFs, order them clearly, merge them, and hand the user back one clean file.

Why I chose the browser first

I chose the browser first because the core workflow benefits directly from local processing.

People do not only merge throwaway PDFs. They merge resumes, certificates, forms, administrative paperwork, study materials, and internal business documents. Once I framed the problem that way, the architecture choice became less abstract. Sending those files to a third-party server might be acceptable for some tools, but it was not the product story I wanted for pdfzus.

Local processing gave me three practical advantages.

First, it improved the privacy model. A browser-based PDF merge flow makes it easier to say, with technical backing, that the document handling is local to the user’s environment.

Second, it reduced backend responsibility. I did not need to begin with upload pipelines, temporary document storage, merge queues, cleanup policies, and all the security questions that come with them.

Third, it made the interaction model better for this specific job. The workflow is inherently visual: add files, change their order, check the set, export. That maps well to a browser UI, especially when ordering is implemented as a real drag-and-drop interaction rather than a table full of “move up” buttons.

This is where @dnd-kit/* matters more than it might seem. In a browser-based PDF merge tool, drag-and-drop ordering is not polish. It is part of the core problem. If ordering feels weak, the entire workflow feels weak.

The stack is simple, but the decision is not

On paper, the stack is not unusual.

• pdf-lib handles core PDF manipulation tasks.

• pdfjs-dist supports rendering and document-facing UI needs.

• @dnd-kit/* supports ordering and interaction.

• React and Next.js hold the product together.

That is a practical stack for a browser-based PDF merge tool. But the decision is not just about libraries. It is about choosing the kind of product you are willing to build.

I think that is the non-obvious part.

A browser-first architecture is not simply the “more modern” option. It is a constraint system. It pushes you toward a certain product shape:

• lighter document workflows

• strong emphasis on immediate interaction

• narrower feature boundaries

• more explicit handling of edge cases

That can be a strength. It can also be a trap if you keep pretending the browser is a general-purpose PDF infrastructure layer.

Where browser-side merge works extremely well

For everyday merge flows, I still think the browser is the right place.

If someone needs to combine a cover letter, resume, and certificates into one application PDF, the browser works well. If a user needs to merge a set of office attachments into one document before sending an email, the browser works well. If the main value is local ordering, fast feedback, and not having to trust an upload-heavy workflow, the browser works well.

That is the sweet spot I had in mind for pdfzus.

The architecture fits that workflow because the job is relatively narrow:

1. load files

2. preview or understand the set

3. reorder them

4. merge them

5. export one result

The tighter the workflow, the stronger the browser-first decision becomes.

This is also where pdfjs-dist earns its place. Merge is not only about the output. It is also about helping users understand what they are merging. Once a tool starts handling multiple documents with ordering, visual context stops being a nice-to-have and becomes part of usability.

What I got wrong at first

My initial assumption was that moving PDF merge into the browser would make the system simpler overall.

That was only half true.

It simplified some parts of the system. It did not simplify the product as a whole.

The complexity moved.

Instead of backend pipelines and storage management, I had to think much harder about browser constraints: memory pressure, file size boundaries, encrypted documents, and the fact that users do not care whether a limitation is caused by the runtime or by my product decisions. They only care that the workflow feels reliable.

That was the real correction in my thinking: browser-side processing does not remove complexity; it relocates it.

And once you accept that, your architecture decisions get better.

You stop asking “can the browser technically do this?” and start asking “is this still the right runtime for the user experience I want to defend?”

That is a much more useful question.

The browser is not the right home for every PDF workload

I would absolutely choose browser-side merge again for pdfzus, but I would not recommend it blindly for every PDF product.

It works well when:

• the workflow is mostly merge, order, and export

• the documents are light to medium in complexity

• privacy is part of the product value

• direct interaction matters more than backend orchestration

It becomes a weaker fit when:

• the files are very large

• the workload becomes heavy batch processing

• encrypted documents or unusual PDF structures are common

• users expect enterprise-style document handling at scale

The repo and research docs already point in that direction. There is repeated discussion around pdf-lib being a strong fit for browser-side merge and page operations, while large files, encrypted PDFs, and more advanced operations push the architecture toward other paths such as WebAssembly-heavy engines, server-side fallbacks, or hybrid designs.

That is another place where I want to be careful. It is easy to take the existence of WebAssembly-related docs and overstate current production detail. I do not want to do that. For this article, WebAssembly is part of the architectural context and design direction around local processing, not a place for me to claim unverified implementation specifics.

What I would do differently in v2

If I were designing the next iteration from scratch, I would make the architecture boundaries even more explicit earlier.

I would define, in the product itself, what browser-side merge is for and what it is not for.

That means:

• clearer file-size and workload expectations

• more obvious messaging around unsupported or high-risk edge cases

• a more deliberate path toward hybrid handling if the product scope expands

• stricter separation between “fast local workflow” and “heavy document processing”

I think many browser-based tools wait too long to make those boundaries visible. They try to preserve the illusion that one architecture can gracefully own every scenario. In practice, that tends to create worse UX, not better architecture.

The lesson I took from pdfzus is that users trust focused tools more than vague tools. And architecture is part of that trust.

My practical advice for developers building this kind of tool

If you are considering a browser-based PDF merge product, I would use these filters.

Choose the browser first if:

• privacy is central to the product story

• your workflow is mostly interactive and lightweight

• drag-and-drop ordering and direct manipulation matter

• you want to avoid backend file infrastructure in the early product

Choose server-side or hybrid earlier if:

• large documents are normal

• encrypted files are common

• batch workloads are part of the core use case

• you need broader PDF operations than merge-focused flows

Most importantly, do not frame the browser as a universal solution. Frame it as a deliberate strategy for a particular kind of document workflow.

That is the architectural decision behind pdfzus. Not “the browser can do PDF merging,” but “for this problem, the browser is the right first runtime.”

Conclusion

A browser-based PDF merge tool is not interesting because it avoids a server. It is interesting because it forces a more disciplined product architecture.

For pdfzus, choosing the browser first made sense because the workflow is focused, privacy matters, and direct ordering is part of the job itself. The tradeoff is that I have to treat runtime limits as first-class design constraints, not as hidden technical debt.

That is the real takeaway I would give another developer: if you want to merge PDFs in the browser, do it because the product shape justifies it, not because local processing sounds cleaner on paper.

When the fit is right, it leads to a better tool. When the fit is wrong, it just moves the pain somewhere less obvious.