For the last two months I've been building a set of file tools that run entirely in the browser. The PDF editor is the one I use most, so that's what this post is about.
The problem ->
Every online PDF tool I tried did the same thing. You upload the file, they process it on a server, they send it back. Smallpdf, iLovePDF, Adobe's free tools, all of them. That's fine for a random utility bill, but it's a problem when the PDF is a contract, a medical form, or anything with personal info on it.
The other option is a desktop app. LibreOffice Draw works, but it's heavy, and it doesn't handle signing well. So I had this gap where nothing fit: something light, browser-based, that didn't require handing my documents to a stranger.
What I did about it
I built the tool so it can't upload your files. Not "we promise not to" but "the architecture doesn't allow it."
It's a static HTML page. There's no backend, no API, no database. The whole thing is JavaScript running in your browser tab. When you drop a PDF in, the File API reads it into memory, and pdf-lib processes it right there. When you download the result, your browser writes the file back out. At no point does anything leave your machine.
You can verify this. Open DevTools, go to the Network tab, and use any tool. Zero outbound requests related to your file.
What the editor actually does
The main operations people seem to want:
Merge multiple PDFs into one
Split by range, or every N pages, or extract individual pages
Rotate pages (the amount of sideways scans in the world is staggering)
Reorder pages by dragging thumbnails
Delete pages
Compress with three quality levels
Add a text watermark, rotated and semi-transparent
Draw a signature with a pen pad, then place and resize it on the page
Add text anywhere on a page, move it around until it sits right
The reader mode was the part I spent the most time on. You open a page, click to place an element, then drag it, resize it with handles, rotate it, delete it, undo and redo. It behaves like a lightweight editor rather than a form filler, which is what most free tools feel like.
The stack, briefly
Plain HTML, CSS, and JavaScript. No framework, no bundler, no build step.
pdf-lib for PDF manipulation
pdf.js for rendering page thumbnails and the reader view
Canvas API for the signature pad
Cloudflare Pages for hosting. It's a static site so there's nothing to scale.
The whole thing is around 2,500 lines of JavaScript in the PDF editor alone, most of which is the overlay element system for the reader. The rest of the site is a handful of smaller tools that share the same pattern.
What I learned along the way
The hardest part wasn't the PDF manipulation. It was the browser quirks. Mobile touch handling for drag and resize on elements that live on top of a canvas. Text input focus on iOS. Making sure that opening DevTools didn't break drag interactions. The libraries handle the file format stuff well; the interaction layer is where you spend all your time.
The honest limitations
It won't open password-protected PDFs. If you know the password, you have to decrypt it elsewhere first.
It can't OCR scanned pages. That would need Tesseract.js, which is a much bigger dependency and slower to load.
It can't edit the existing text in a PDF. PDFs aren't structured documents, they're a series of drawing instructions. Inserting new text is easy, changing existing text is a research project.
It's also browser-memory-bound. On a phone with 4GB of RAM, a 200 MB PDF is going to struggle. On desktop it handles everything I've thrown at it.
Why I'm posting this
Partly to show the approach, since "just do it in the browser" solves a category of problems that don't need a server at all. Partly because I want to know what other people are doing for the same task. LibreOffice Draw, PDFgear, and some browser extensions all handle parts of this, and I'd like to know what I'm missing.
The full editor is at soroflix.xyz/pdf-editor/ if you want to try it. No account, no signup, no limits. It's free.
Happy to answer questions about the implementation, the libraries, or why the overlay system was the hardest part.
Top comments (0)