How I built FreePDF.lol using Next.js, WebAssembly, PDF.js, and pdf-lib to process documents without uploading a single file.
#The Problem
Open almost any online PDF editor today and you'll see the same workflow:
- Upload your document to someone else's server.
- Wait while it processes.
- Download the modified file.
- Hope your document gets deleted afterward.
For public documents, that's usually fine.
For contracts, resumes, financial statements, IDs, invoices, medical reports, or internal company documents, it isn't.
Every upload introduces an unnecessary privacy risk.
I wanted something different.
Instead of asking users to trust my servers, I asked a different question:
What if the browser could do all the work?
That idea eventually became FreePDF.lol.
#Why Build Everything in the Browser?
Modern browsers are far more capable than they were a few years ago.
With APIs like:
- File System Access
- Web Workers
- IndexedDB
- Canvas
- WebAssembly
the browser has become a surprisingly powerful runtime.
That meant I could build a PDF editor where:
- files never leave the device
- no backend is required for document processing
- processing starts instantly
- users keep complete control of their data
Instead of this:
`text
Browser
↓
Upload
↓
Server
↓
Process
↓
Download
`
the architecture became:
`text
Browser
↓
PDF.js
↓
pdf-lib
↓
WebAssembly
↓
Download
`
The server never sees the document.
#Choosing the Stack
The goal wasn't to use trendy technologies.
It was to build something that felt native.
#Next.js
Next.js handled the application framework, routing, SEO, and deployment.
Since processing happens client-side, the server mostly delivers the application shell.
#TypeScript
Working with binary files is error-prone.
TypeScript catches mistakes before users do.
Strong typing became especially valuable when manipulating PDF structures and page objects.
#PDF.js
Rendering PDFs inside the browser sounds simple.
It isn't.
PDF.js parses the PDF specification and renders each page accurately using the browser.
Without it, previews wouldn't be possible.
#pdf-lib
Rendering is only half the problem.
Actually modifying PDFs requires another library.
pdf-lib became the backbone for operations like:
- merging PDFs
- splitting documents
- rotating pages
- adding page numbers
- inserting watermarks
- deleting pages
Everything happens entirely in memory.
#WebAssembly
Some operations, especially compression and OCR, are computationally expensive.
Instead of sending those jobs to a server, they're executed locally using WebAssembly-powered libraries.
That gives users desktop-like performance without sacrificing privacy.
#The Hardest Part Wasn't Building the UI
It was managing memory.
Large PDFs can easily contain hundreds of pages.
Naively loading every page into memory causes browsers to freeze.
Instead, I had to think about:
- lazy page rendering
- releasing unused objects
- avoiding unnecessary copies
- efficient ArrayBuffer handling
- incremental processing
Performance wasn't just about speed.
It was about making the application usable on average laptops.
#Why There Is No Login
Almost every PDF website asks you to create an account.
I intentionally didn't.
No accounts.
No uploads.
No subscriptions just to merge two PDFs.
If your files never leave your browser, I don't need your email address.
That's one less thing for both of us to worry about.
#Scaling Without Processing Files
An interesting side effect of client-side processing is infrastructure cost.
Traditional PDF services pay for:
- compute
- storage
- bandwidth
- background workers
FreePDF.lol doesn't process user files on the server.
That means the infrastructure only serves the web application itself.
The heavy lifting happens on the user's machine.
It's a very different scaling model.
#SEO for a JavaScript Application
One challenge wasn't technical. It was discoverability.
With dozens of PDF tools, I wanted each tool to be independently discoverable.
That led to:
- programmatic SEO
- structured metadata
- optimized routing
- performance-focused rendering
- Core Web Vitals optimization
The result is a growing library of searchable tools instead of a single landing page.
#Lessons Learned
Building a browser-native PDF editor taught me much more than PDF manipulation.
It reinforced a few ideas:
- Modern browsers are far more capable than most developers realize.
- Privacy can be a feature, not just a compliance checkbox.
- Good performance comes from architecture, not animations.
- Sometimes removing the backend entirely is the simplest solution.
#What's Next?
FreePDF.lol currently includes dozens of tools, but there are still interesting problems left to solve:
- smarter OCR
- AI-assisted document editing
- better table extraction
- improved compression algorithms
- offline-first workflows
- collaborative document features without sacrificing privacy
The browser keeps getting more powerful every year.
I'm excited to see how far it can go.
#Final Thoughts
When I started this project, I wasn't trying to build another PDF website.
I wanted to challenge the assumption that document processing must happen on someone else's server.
It turns out the browser is capable of far more than we usually give it credit for.
If I can merge, split, edit, compress, sign, and convert PDFs entirely on your device, maybe the future of many web applications isn't more backend. Maybe it's simply making better use of the browser.