I Run 36 PDF Tools on $0/Month: The Architecture Nobody Believes

Series: Building PdfWord — a free, no-backend PDF tools site (Part 17)

Every time I tell a developer that PdfWord runs 36 PDF tools with zero backend, zero server costs, I get the same reaction: disbelief, then "okay but how do you actually do the conversions?"

So here's the full architecture. No secrets.

The core insight

A modern browser is a shockingly capable computer. It can:

• Parse and generate PDFs (pdf-lib)
• Render PDF pages to canvas (PDF.js)
• Run OCR (Tesseract.js with WebAssembly)
• Convert Office documents (Mammoth.js for Word, SheetJS for Excel)
• Process images (native Canvas API)
• Store files locally (IndexedDB)

Every "server" task in a PDF pipeline maps to a client-side library. The only thing the browser can't do cheaply is heavy work like Ghostscript-grade compression — and for that, Canvas re-rendering gets you 80% of the way there.

The stack

• Hosting: Cloudflare Pages (free tier, global CDN)
• PDF engine: pdf-lib + PDF.js, loaded per-tool (never on the homepage)
• OCR: Tesseract.js v5, WASM, English traineddata shipped locally
• PWA: Service worker, offline-first for the app shell
• Analytics: Cloudflare Web Analytics (privacy-friendly, free)
• Total monthly cost: $0

The rules that make it work

1. Never load what the page doesn't need. The homepage loads 15KB of JS. Tool libraries load only on their own pages. This is the difference between a 100/100 PageSpeed score and a bloated mess.

2. Precache the shell, not the tools. The service worker caches the app shell (~120KB). Heavy libraries cache on-demand after first use. Precaching 2MB of WASM made the installed app open slowly — learned that the hard way.

3. Files never leave the device. This isn't just a privacy feature, it's an architecture feature: no upload bandwidth, no processing queues, no storage costs, no GDPR data-processing agreements.

4. Bump the service worker every deploy. The SW only self-updates when its bytes change. Forget this once and users run stale code forever.

What I'd do differently

Honest retrospective: I'd have built the SEO landing pages first, not last. 36 tools with no discoverability is a tree falling in an empty forest. Traffic is the feature I under-invested in.

The takeaway

If your app's workload fits in a browser tab, you probably don't need a backend. You need discipline about what loads when — and the courage to delete the server.

PdfWord is free forever: 36 PDF tools, no signup, no watermark, everything runs in your browser. Try it: https://pdfwordtools.pages.dev