DEV Community: RB

How I cut my AWS bill to $0 by moving my backend to the browser (WebAssembly)

RB — Tue, 16 Jun 2026 06:52:34 +0000

A few months ago, I was mapping out the architecture for a heavy file-processing application. The traditional SaaS playbook was obvious:

User uploads a heavy file.
Store it in an AWS S3 bucket.
Spin up an EC2 instance or AWS Lambda function to process it.
Send the result back to the client. But when I ran the numbers on processing thousands of 50MB files a day, the AWS bandwidth and compute costs were terrifying. Worse, uploading user files to my servers introduced massive privacy and GDPR liabilities. I realized the traditional client-server model was the wrong approach. Modern browsers are incredibly powerful machines. Why was I paying Amazon to process files when the user has an M1 Mac or a Snapdragon processor sitting right in front of them? I decided to ditch the backend entirely and move the heavy lifting to the client using WebAssembly (WASM). Here is how I did it, and how you can apply this architecture to your own apps. --- ## The Paradigm Shift: Client-Side Compute If you haven't played with WebAssembly yet, it fundamentally changes what you can build on the web. WASM allows you to compile languages like C, C++, and Rust into a binary format that runs directly inside the browser at near-native speeds. Instead of sending data to the server, you send the server logic to the data. ### The Use Case: PDF Pro To prove this architecture worked at scale, I built PDF Pro—a suite of tools that compress, merge, and edit massive PDF files. Traditionally, PDF manipulation requires heavy server-side libraries like Ghostscript. But by bridging JavaScript with WASM-compiled PDF engines, I was able to invert the entire flow. Here is the exact architecture I used to process files entirely in the user's RAM: ### 1. Intercepting the File Locally Instead of wrapping the file input in a <form action="/upload">, we intercept the file locally using the File API.

`document.getElementById('fileInput').addEventListener('change', async (event) => {
const file = event.target.files[0];

// Load the file into the browser's memory (RAM)
const arrayBuffer = await file.arrayBuffer();

// Pass the buffer to the WASM engine instead of an API
processFileLocally(arrayBuffer);
});`

2. Processing in the Sandbox

Once the file is an ArrayBuffer in the browser's memory, we pass it to the WASM engine.
For PDF Pro, the WASM engine tears down the binary structure of the document, strips out metadata, and uses the browser's native <canvas> API to intelligently downsample heavy images.
Because WASM runs at near-native speeds, a 20MB file that would normally take 15 seconds to upload to an AWS server is processed locally in about 1.5 seconds.

3. Returning the Result

Once the WASM engine finishes processing, it generates a new binary Blob. We use URL.createObjectURL() to instantly trigger a download back to the user's hard drive.
`javascript
function triggerLocalDownload(processedBytes, filename) {
const blob = new Blob([processedBytes], { type: 'application/pdf' });
const url = URL.createObjectURL(blob);

const a = document.createElement('a');
a.href = url;
a.download = optimized_${filename};
a.click();

URL.revokeObjectURL(url); // Clean up memory
}

`

The 3 Massive Benefits of this Architecture

If you are building a tool that handles images, video, audio, or document processing, you should strongly consider moving it to the client.

Infinite Scaling for $0: Because the compute happens on the user's device, my server costs are identical whether I have 10 users or 100,000 users. I only pay for static frontend hosting (Vercel/Netlify).
Zero Privacy Liability: I don't have to worry about hackers breaching my S3 buckets or GDPR compliance, because I never receive the user's data. It never leaves their laptop.
Instant UX: There are no loading bars while a user waits for a 50MB file to upload over a slow 3G connection. The processing starts instantly. ## See it in action If you want to see how fast this architecture actually feels in production, you can test the live app here: PDF Pro Local Compressor. You can literally load the page, turn off your Wi-Fi, and it will still process your files flawlessly. I also open-sourced the underlying WASM architecture on GitHub if you want to poke around the code: GitHub Repo. Have you started using WebAssembly in your side projects yet? I'd love to hear what use-cases you think this client-side architecture fits best!

Why We Stopped Sending Sensitive Documents to the Cloud (and Built a Local-First AI Analyzer Instead)

RB — Fri, 12 Jun 2026 12:05:27 +0000

If you are a startup founder, you know the drill. You spend weeks agonizing over financial projections, customer acquisition costs, and intellectual property details to build the perfect Pitch Deck.
If you run an agency, you know the pain of reading a 50-page Enterprise RFP (Request for Proposal), terrified that you might miss a single ISO compliance requirement that instantly disqualifies your bid.
Naturally, in 2024, the first instinct is to upload these massive PDFs to ChatGPT or Claude and ask for a summary.
Stop doing this.
When you upload your unreleased pitch deck, your NDA-protected contracts, or your dense insurance policies to public AI chat interfaces, you are feeding your highly sensitive data into remote cloud servers.
We realized this was a massive security flaw for B2B users. So, we decided to build a completely private alternative.

Here is how we built a 100% private, local-first AI Document Intelligence platform using WebAssembly, and why you should care.

The Privacy Problem with Cloud AI

Most "AI PDF Summarizers" on the market work like this:

You drag and drop your PDF.
The file is uploaded to an AWS S3 bucket.
A backend server parses the text.
The text is sent to an LLM provider.
The result is returned to you. The problem is step 2. Your file is now sitting on a server you don't control. For a high-stakes Enterprise RFP under strict NDA, or a Pitch Deck with unannounced IP, this is a fatal breach of data security protocols. ## Enter WebAssembly (Wasm) We wanted the power of AI analysis, but the privacy of a desktop application. The solution was WebAssembly. Instead of uploading the PDF to our servers, we process the file entirely within the user's browser. Here is the architecture we landed on for PDF Pro AI:
Client-Side Parsing: We use a WebAssembly build of Mozilla's pdf.js (pdf.worker.min.mjs). When a user drops a file, the Wasm engine spins up directly in their Chrome/Safari browser.
Local Extraction: The text extraction happens locally on the user's RAM. The .pdf file itself never leaves their device via a network request.
Targeted AI Routing: Once the text is extracted locally, only the raw text strings are sent via a secure, transient API call to the LLM (bypassing any file storage mechanisms).
Zero-Retention: Because we never receive the file, there is nothing to store, nothing to leak, and nothing to train future models on. ## The Use Cases We Built It For Once we nailed the local-first extraction pipeline, we realized we could fine-tune the AI prompts for highly specific, high-risk B2B documents. We just launched two specific tools built on this architecture: ### 1. The RFP & Pitch Deck Analyzer We wrote a dynamic prompt architecture that changes based on the document type:
For Pitch Decks: The AI is instructed to act as a harsh Venture Capitalist. It completely ignores marketing fluff and actively hunts for missing financial metrics (CAC, LTV, Burn Rate) to give you realistic feedback before you pitch.
For Enterprise RFPs: The AI acts as a Procurement Officer. It ignores the company history and strictly extracts hard compliance requirements, ISO certifications, and deadlines, ensuring you don't waste 40 hours writing a bid you are legally disqualified from winning. Try the RFP & Pitch Deck Analyzer here (Free Beta) ### 2. The Insurance Policy Analyzer Insurance companies make money by burying exclusions in 60-page PDFs. We trained the AI to act as a skeptical claims adjuster. It scans Health, Life, and Auto policies specifically to extract deductibles and summarize the "Hidden Exclusions" (like pre-existing condition loopholes) in plain English. Try the Insurance Policy Analyzer here ## The Future is Local-First As AI continues to integrate into professional workflows, the divide between "convenient" tools and "secure" tools will grow. By leveraging WebAssembly for client-side processing, we can give users the best of both worlds: Enterprise-grade AI analysis, without sacrificing document privacy. If you are a founder dealing with pitch decks, or an agency dealing with NDAs and RFPs, try processing them locally first. Your IP will thank you. --- Built with Next.js, WebAssembly, and Gemini. Check out the full suite of private document intelligence tools at PDF Pro.

How We Built a Zero-Upload PDF Editor in WebAssembly to Beat the $108/yr Paywalls

RB — Thu, 11 Jun 2026 09:56:26 +0000

For years, whenever I needed to merge two PDFs or compress a file to upload to a government portal, I would Google "compress PDF", click the first result, and inevitably hit a paywall.
"You have reached your 2 free files per day limit."
Worse, I was uploading sensitive documents—tax returns, medical records, and NDAs—to random servers in God-knows-where just to strip out some heavy images.
I decided to build an alternative. I wanted it to be 100% free, have absolutely no daily limits, and most importantly: zero server uploads.
Here is how we built PDF Pro using Next.js and WebAssembly to process PDFs entirely natively inside the user's browser.

The Architecture: Why WebAssembly?

Traditional PDF tools (like Smallpdf or iLovePDF) use a monolithic server architecture. You upload your file to their AWS bucket, their backend runs a Python or C++ script (usually using Ghostscript or a proprietary library) to manipulate the PDF, and then you download the processed file.
This architecture is expensive (high bandwidth and compute costs) and creates a massive privacy liability.
By compiling a C++ PDF manipulation library down to WebAssembly (WASM), we inverted the architecture.

1. The Build Process

We took pdf-lib and custom C++ compression algorithms and compiled them to a lightweight .wasm binary. When a user visits PDF Pro Compress, their browser downloads the ~2MB WASM file once and caches it.

2. Client-Side Processing

When you drag and drop a 50MB PDF into the UI, it never hits our server. Instead, the browser's JavaScript engine passes a Pointer to the file data directly into the WebAssembly memory buffer. The WASM module executes native C++ speeds directly on your local CPU to compress or merge the document.

Performance Benchmarks

Because there is zero upload and zero download time, the performance metrics are staggering:

10MB PDF Compression (Cloud): ~15 seconds (Upload) + 4 seconds (Process) + 5 seconds (Download) = 24 seconds.
10MB PDF Compression (PDF Pro WASM): 0 seconds (Upload) + 1.2 seconds (Process) + 0 seconds (Download) = 1.2 seconds. It's nearly 20x faster because the speed of light (internet latency) is no longer a factor. ## The SEO Challenge: Competing with Giants Building a better tool is only half the battle. The incumbents have millions of backlinks and dominate the root keyword "compress pdf". To compete, we employed a highly aggressive Programmatic SEO strategy. Instead of fighting for the root keyword, we programmatically generated hundreds of hyper-specific landing pages tailored to the exact problem the user is trying to solve. Instead of searching "compress PDF", users search for Compress PDF to 1MB for Passport Seva or Merge Bank Statements securely. Because our landing pages exactly match the search intent, Google ranks them highly, completely bypassing the massive marketing budgets of the incumbents. ## Try it out (And check the Network Tab!) If you want to see the architecture in action, try merging a few files at PDF Pro. Open your Chrome Developer Tools, head to the Network tab, and hit merge. You will see absolutely zero network requests firing. Your files never leave your machine. It's 100% free, unlimited, and private. Let me know what you think of the WebAssembly implementation in the comments!

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.