DEV Community: RB

Stop sending user PDFs to random cloud APIs (how to do it locally) published

RB — Mon, 08 Jun 2026 11:59:48 +0000

I recently had to build a feature where users could merge a bunch of invoices and scan them for specific keywords.

My first instinct was to do what I always do: grab an API key from Adobe or some generic PDF service, send the file to their server, wait 4 seconds, and get the merged file back.

But looking at the actual data—these were medical bills and tax documents—I realized how insane that workflow is. Why are we conditioning users to upload highly sensitive documents to random AWS buckets just to stitch two pages together? It’s a massive privacy risk, and honestly, the API latency is annoying.

I spent the weekend ripping out the backend API and forcing everything to run client-side. Here is what I learned.

You don't need a backend for PDF manipulation anymore
If you haven't checked out pdf-lib recently, you should. It compiles down to WebAssembly, which means your browser can chew through binary PDF manipulation just as fast as a Node backend.

I threw together a simple utility function. No Express server, no AWS S3 buckets, no waiting for a network request to finish.

import { PDFDocument } from 'pdf-lib';

// Runs entirely in the browser
async function mergeLocally(file1, file2) {
  const pdf1 = await PDFDocument.load(await file1.arrayBuffer());
  const pdf2 = await PDFDocument.load(await file2.arrayBuffer());

  const merged = await PDFDocument.create();

  // Copy and append pages
  const p1 = await merged.copyPages(pdf1, pdf1.getPageIndices());
  const p2 = await merged.copyPages(pdf2, pdf2.getPageIndices());

  p1.forEach(page => merged.addPage(page));
  p2.forEach(page => merged.addPage(page));

  // spit out a blob for the user to download
  const bytes = await merged.save();
  return new Blob([bytes], { type: 'application/pdf' });
}

That’s literally it.

I got a bit obsessed with the "Zero Upload" architecture. Once I realized how snappy it felt to bypass the network tab entirely, I ended up building an entire UI around it.

I put it live at PDF Pro AI just to see how far I could push browser-based processing. I even got a Contract Analyzer working that extracts text locally via WASM before doing any AI checks, so the physical PDF never touches my database.

If you're building SaaS products that handle NDAs, tax forms, or medical records, give client-side parsing a shot. It completely eliminates your server costs for file processing, and more importantly, you don't have to worry about accidentally leaking your users' files.

Has anyone else completely ditched backend PDF rendering, or is there a use-case I'm missing where server-side is still strictly better?

Why I Built My Free PDF Editor with WebAssembly (Zero Server Uploads)

RB — Fri, 22 May 2026 13:13:08 +0000

If you’ve ever tried to compress a bank statement or merge sensitive PDF documents online, you’ve probably noticed the process: you upload the file, wait for a progress bar, and then download the result.

But what happens to that file on the server?
Most free PDF tools (like ILovePDF or Smallpdf) upload your highly sensitive documents to remote servers to process them. This is a massive privacy risk for documents containing PAN cards, Aadhaar numbers, and financial statements.

To solve this, I built PDF Pro.

Why WebAssembly (WASM)?

Instead of sending your files to a server, I used WebAssembly to compile a heavy C++ PDF processing library directly into Javascript.

This means the entire PDF engine runs locally inside your browser.

Zero Uploads: Your file literally never leaves your computer.
Instant Speed: Because there is no network latency, compressing a 10MB file happens in milliseconds instead of minutes.
100% Free: No servers means no cloud computing costs. I can afford to offer this tool completely free with zero daily limits.

Built for the Indian Web

I specifically optimized PDF Pro to target government portal limits. The Staff Selection Commission (SSC) and UPSC require documents to be strictly under 200KB.

Instead of arbitrarily dropping quality and making your scanned certificates blurry, the WebAssembly engine strips embedded fonts and intelligently down-samples resolution to exactly 150 DPI—maintaining crystal clear vector text while satisfying the portal sizes.

If you are a developer, CA, or student tired of uploading your personal data to random websites, try it out: PDF Pro - Free & Private PDF Tools.

ShowDev: I built a 100% local, zero-upload PDF editor using WebAssembly

RB — Thu, 21 May 2026 13:36:08 +0000

Why I Built a Privacy-First PDF Tool for India's Government Portals (And the Tech Behind It)
Updated
May 20, 2026
•
5 min read
RahulBanerjee
RahulBanerjee
Part of series
Building in Public — PDF Pro
Every Indian who has applied for a government job, filed an ITR, or renewed their passport knows the frustration I'm about to describe.

You have spent hours gathering your documents — Aadhaar card, PAN card, marksheets, photographs. You open the portal. You upload your carefully scanned PDF. And then you see it:

❌ "File size exceeds the maximum limit of 200KB. Please upload a smaller file."

Your file is 2.1MB. You try again. 1.8MB. Still rejected. You are now frantically Googling "how to compress PDF online free" at 11:45 PM, the night before the application deadline.

Every tool you find has the same catch: upload your document to our servers first.

That is exactly the problem I set out to solve.

The Privacy Problem Nobody Talks About Think about what you are uploading when you use a typical online PDF compressor:

Your Aadhaar card (your national identity number) Your PAN card (your tax identity) Your bank statements (your complete financial history) Your ITR filings (income, assets, liabilities) These files are being sent to servers in the US, Europe, or wherever the company is hosted. You have no idea what happens to them after processing. Are they stored? For how long? Are they used to train AI models? Are they sold?

Most privacy policies of these tools are vague at best and alarming at worst.

When I dug into this problem, I realized the solution already existed in the browser. We just weren't using it.

The Solution: WebAssembly Changes Everything Modern browsers ship with a technology called WebAssembly (Wasm) — a binary instruction format that lets you run near-native speed code directly inside the browser sandbox.

Libraries like pdf-lib and Ghostscript compiled to Wasm mean you can run a full PDF compression engine entirely inside the user's browser tab.

Here is what this means practically:

Traditional Cloud Tool: User → Upload file to server → Server compresses → Download result ↑ Your private document lives on their infrastructure PDF Pro (Wasm-based): User → File loads in browser memory → Browser compresses locally → Download result ↑ Your document never leaves your computer The file never touches a remote server. Not even for a millisecond.

Building PDF Pro I built PDF Pro (https://pdfpro.co.in) as a Next.js application with a Wasm core. Here is the architecture in plain terms:

Frontend: Next.js 16 (App Router) hosted on Vercel PDF Engine: WebAssembly-compiled compression libraries running client-side Analytics: Google Analytics for aggregate visitor counting only — no PII Backend: None. There is no backend that touches your files.

The stack is intentionally minimal. The less infrastructure you have, the less can go wrong from a privacy standpoint.

The Compression Challenge Government portals in India have wildly different file size requirements:

Portal Limit UPSC IAS Application 200KB SSC CGL 200KB IBPS PO 500KB Passport Seva 1MB ITR Filing 1MB Visa Application 1MB Building a single tool that handles all these targets while preserving document readability was the core engineering challenge. Too aggressive on compression and your Aadhaar number becomes unreadable. Too gentle and the portal rejects the file.

The solution was letting the user control the compression level explicitly, with a real-time preview of the output file size before they download.

What I Learned Building This

Indian users are underserved by Western productivity tools Most global PDF tools are built for English-speaking Western users filing corporate documents. The specific pain point of compressing identity documents for strict-size government portals is a uniquely Indian problem that nobody was solving well.

Privacy is a feature, not a checkbox When I started describing PDF Pro as "your files never leave your browser," the response from users was immediate and emotional. People care about this. They had just never had a tool that made it the central promise.

WebAssembly is criminally underused in productivity tools The performance of Wasm-compiled PDF libraries surprised even me. Compression that would take a server round-trip (upload → process → download) now completes in under 3 seconds on a mid-range phone, entirely offline, with no latency.

The Bigger Picture We talk a lot in the developer community about building products for global audiences. But there are 1.4 billion people in India navigating government digital infrastructure that was not designed with them in mind.

If you know WebAssembly, you have a genuine superpower to fix these problems — tools that work offline, respect privacy by design, and don't require a subscription or an account.

PDF Pro is proudly built in India. Not as a marketing line, but as a genuine statement of intent about who this tool is for.

Try It The tool is completely free with no account required:

👉 https://pdfpro.co.in

If you are a developer curious about the Wasm implementation, feel free to reach out at rahulorama@gmail.com . I am happy to discuss the technical architecture in more detail.

And if you are an Indian developer building tools for Indian problems — I would love to connect. This space needs more of us.

Rahul Banerjee is an independent developer based in India. He builds privacy-first productivity tools using modern web technologies.

DEV Community: RB

Stop sending user PDFs to random cloud APIs (how to do it locally) published

Why I Built My Free PDF Editor with WebAssembly (Zero Server Uploads)

Why WebAssembly (WASM)?

Built for the Indian Web

ShowDev: I built a 100% local, zero-upload PDF editor using WebAssembly

webdev

javascript

webassembly