Six months ago I needed to compress my tax return. Googled it, uploaded to the first site I found, then thought: "Wait, where did my file just go?"
That uncomfortable feeling led to PDFfreeEditor – a PDF tool where files never leave your browser.
The architecture:
Instead of upload → server process → download, everything happens client-side with WebAssembly. Your PDF stays in browser memory, gets processed locally, and you download the result.
Why this matters:
- Your sensitive docs (taxes, contracts, medical records) never hit a server
- Faster for most files (no upload latency)
- Scales infinitely (users provide the compute)
- Zero server costs (I serve 50K users for $0/month)
Technical details:
- PDF.js parses the PDF structure
- Custom WASM module handles compression (C compiled to WASM)
- Chunked processing for large files (prevents memory crashes)
- Service Worker makes it work offline
What surprised me:
40% of users specifically mentioned privacy in feedback. There's real demand for tools that don't upload your data.
What I'd do differently:
- Start with TypeScript (dealing with complex PDF structures in JS was painful)
- Add privacy-friendly telemetry earlier (I don't know which features are actually used)
- Open source from day 1 (doing it now, late)
The economics are interesting:
Traditional PDF service: $125-550/month in server costs
My costs: $0/month (Cloudflare Pages free tier)
Trade-off: Users with slow devices have slower processing. But they get perfect privacy in exchange.
I'm here all day to answer questions about:
- WebAssembly implementation
- Client-side architecture decisions
- Why I think "no backend" is underutilized
- PDF.js internals
- Scaling without infrastructure
Six months ago I needed to compress my tax return. Googled it, uploaded to the first site I found, then thought: "Wait, where did my file just go?"
That uncomfortable feeling led to PDFfreeEditor – a PDF tool where files never leave your browser.
The architecture: Instead of upload → server process → download, everything happens client-side with WebAssembly. Your PDF stays in browser memory, gets processed locally, and you download the result.
Why this matters: - Your sensitive docs (taxes, contracts, medical records) never hit a server - Faster for most files (no upload latency) - Scales infinitely (users provide the compute) - Zero server costs (I serve 50K users for $0/month)
Technical details: - PDF.js parses the PDF structure - Custom WASM module handles compression (C compiled to WASM) - Chunked processing for large files (prevents memory crashes) - Service Worker makes it work offline
What surprised me: 40% of users specifically mentioned privacy in feedback. There's real demand for tools that don't upload your data.
What I'd do differently: - Start with TypeScript (dealing with complex PDF structures in JS was painful) - Add privacy-friendly telemetry earlier (I don't know which features are actually used) - Open source from day 1 (doing it now, late)
The economics are interesting: Traditional PDF service: $125-550/month in server costs My costs: $0/month (Cloudflare Pages free tier)
Trade-off: Users with slow devices have slower processing. But they get perfect privacy in exchange.
I'm here all day to answer questions about: - WebAssembly implementation - Client-side architecture decisions - Why I think "no backend" is underutilized - PDF.js internals - Scaling without infrastructure
Live demo: https://pdffreeeditor.com
What questions do you have?