DEV Community

Cover image for Building Fillora PDF: Why We Moved Heavy PDF Processing to Client-Side WebAssembly
Rick M
Rick M

Posted on

Building Fillora PDF: Why We Moved Heavy PDF Processing to Client-Side WebAssembly

#webdev #architecture #performance #javascript

Building Fillora PDF: Moving PDF Processing from Server APIs to Browser-Native Execution

Every developer who has built document conversion features has probably encountered the same challenges: large file uploads, server memory pressure, processing queues, timeout limits, and users who hesitate to upload sensitive documents to third-party servers.

When building Fillora PDF, we redesigned many of our core PDF manipulation tools to run directly inside the browser instead of relying on server-side processing.

This article explains why we made that architectural decision, how modern browser APIs make it practical, and the trade-offs we discovered along the way.

🏗️ Server Processing vs. Browser-Native Processing

Traditional online PDF tools typically process every operation on a remote server.

Traditional Server Workflow

Browser
   │
   ├── Upload PDF
   ▼
Server
   │
   ├── Process Document
   ▼
Browser
   └── Download Result
Enter fullscreen mode Exit fullscreen mode

While this approach works well, it introduces several challenges:

  • Upload latency for large files
  • Higher server CPU and memory usage
  • Increased bandwidth costs
  • Privacy concerns when processing sensitive documents
  • Scalability challenges during traffic spikes

For many PDF editing operations—such as merging, splitting, rotating, rearranging pages, and metadata editing—the browser is now capable of doing the work locally.

Browser-Native Workflow

Browser
   │
   ├── Read Local File
   ├── Process Document
   └── Download Result
Enter fullscreen mode Exit fullscreen mode

In this model:

  • Documents do not need to be uploaded for supported browser-native operations.
  • Processing happens on the user's device rather than consuming server CPU.
  • Users receive immediate results without waiting for upload and download cycles.

⚡ Why Modern Browsers Can Handle PDF Processing

Modern browsers provide powerful APIs that make client-side document processing practical.

Some of the key building blocks include:

  • FileReader API for reading local files
  • Blob and URL.createObjectURL() for generating downloadable files
  • ArrayBuffer and Uint8Array for binary data manipulation
  • JavaScript libraries such as pdf-lib for PDF editing
  • Web Workers for moving heavy processing off the main UI thread

A simplified merge example looks like this:

import { PDFDocument } from "pdf-lib";

async function mergePdfFiles(buffers) {
  const mergedPdf = await PDFDocument.create();

  for (const buffer of buffers) {
    const source = await PDFDocument.load(buffer);

    const pages = await mergedPdf.copyPages(
      source,
      source.getPageIndices()
    );

    pages.forEach((page) => mergedPdf.addPage(page));
  }

  return await mergedPdf.save();
}
Enter fullscreen mode Exit fullscreen mode

Because the entire operation runs locally, many everyday PDF tasks can complete quickly without requiring the document to leave the user's device.

🧵 Keeping the Interface Responsive

One challenge with client-side processing is preventing expensive operations from freezing the interface.

Heavy computations performed on the main thread can block rendering and make the application feel unresponsive.

To avoid this, long-running tasks can be executed inside Web Workers, allowing the browser to continue rendering the interface while processing documents in the background.

The result is a smoother experience, especially when working with larger files.

⚖️ Trade-offs We Encountered

Moving processing into the browser is not a universal solution.

Several practical limitations remain.

1. Browser Memory Limits

Browsers enforce memory limits per tab.

Very large PDFs or documents containing thousands of pages can exhaust available memory, particularly on mobile devices.

2. Complex Document Formats

Converting richly formatted Office documents into PDF often requires sophisticated rendering engines.

These workloads are generally better suited to dedicated server-side services.

3. Bundle Size

Adding every processing engine to the initial application bundle would significantly increase page load times.

We therefore load only the functionality required for the current tool whenever possible.

4. Fallback Processing

Some workloads simply exceed what browsers can comfortably handle.

In those situations, server-side processing remains an important fallback.

📈 What Changed

For browser-native PDF operations we observed several practical benefits:

  • Reduced server infrastructure costs
  • Lower bandwidth consumption
  • Faster perceived performance by eliminating upload delays
  • Improved privacy for supported workflows
  • Better scalability because document processing no longer depends on server compute

Rather than replacing server processing entirely, we found that a hybrid architecture works best:

  • Browser-native execution for supported PDF editing tasks
  • Server-side processing only when the workload genuinely requires it

💬 Final Thoughts

Modern browsers have evolved into powerful application platforms.

Features that once required dedicated backend infrastructure can now often be performed directly on the user's device using standard browser APIs and mature JavaScript libraries.

For us, moving many PDF operations into the browser simplified our infrastructure while providing a faster and more privacy-friendly experience for users.

If you've built browser-native document tools, I'd love to hear what approaches worked well for you.

You can explore our implementation at https://fillorapdf.com.

Top comments (0)