Building DSPDF — The Story Behind the Tools

Here's the moment I decided to build this. I was trying to compress a 40 MB PDF so I could email it to a client. The first site I found wanted me to upload it. Fine, I thought. Then the site wanted me to sign up for an account. Then it wanted me to verify my email. Then the compression succeeded and the download link worked for 30 minutes, after which it expired — and by then I'd closed the tab.

My client's file was 40 MB, on a server I didn't own, associated with an account I'd been forced to create, and I couldn't even download the result without re-doing the whole thing.

I've been a developer for years. I knew the operations this website was doing — read a file, compress it, return it — were entirely possible in a browser. The server was only there because servers make it easier to monetise. So I built the tool I wished existed.

Why not just use a server?

Servers are easier in almost every way. You can use any library. You can throw compute at a problem. You can log, cache, and analyse. You can charge for it. You can build a business on it.

The only thing you can't do with a server is guarantee the user's file never left their device. And for a large class of documents — contracts, medical records, tax filings, personal IDs — that guarantee is the whole point.

Users don't always realise it. They see a friendly UI and a "files deleted after 1 hour" promise, and they upload. But "deleted after 1 hour" means the file existed on someone else's infrastructure for an hour, in a location they can't audit, subject to terms they didn't read, potentially backed up, logged, or compromised during that hour.

I wanted to build something where that sentence — "the file was on someone else's server" — simply cannot be true. Not because we promise to delete it. Because it was never there.

The first tool

I started with Merge PDF. It's the simplest operation conceptually — read several files, copy their pages into a new one, save. But it forced me to make decisions about the whole architecture early.

The core libraries are pdf-lib for manipulating PDFs (creating, merging, saving) and pdf.js for rendering them (drawing to canvas). Both are open-source, both are mature, both run fine in a browser.

The first version was three files and about 400 lines. It worked. I remember the small pleasure of merging three PDFs and seeing the output download without any network activity in DevTools. The proof was right there: nothing left my machine.

Technical choices

A few decisions shaped everything after that:

Static site, no backend

DSPDF is hosted as static files — HTML, CSS, JavaScript. No application server. No database. Nothing running when no one is visiting. This is a constraint that forces good behaviour: we can't accidentally start collecting data because there's nowhere to put it.

Web Workers for heavy operations

Merging 20 PDFs of 5 MB each takes a second or two. Doing that on the main thread would freeze the UI — buttons wouldn't respond, animations would stutter. Moving the merge into a Web Worker keeps the interface smooth and lets the user see a progress bar that actually reflects work being done.

Lazy-loaded libraries

The homepage doesn't load any PDF libraries. The merge page loads pdf-lib but not pdf.js. The OCR page loads Tesseract only after the user clicks "Run". Every page pulls only what it needs. This keeps page loads fast even on slow connections.

No analytics by default

The site ships with analytics off. If someone deploying a copy wants to know how many visits they're getting, they can turn it on in a config file. But the default is: no tracking. Not because we're against analytics as a concept, but because "off by default" is a small daily reminder that we can choose to collect less.

Client-side PDF editor with overlay model

The PDF editor was the hardest piece. Editing existing PDF text — genuinely rewriting it in place — is not possible in a browser with current open-source libraries. We made a deliberate choice: build a good overlay editor (add text, images, shapes, signatures on top of the PDF) rather than fake the ability to edit existing content.

Every other online "PDF editor" does one of two things: either it uploads to a server (and often uses commercial PDF SDKs), or it pretends to edit text but really just puts an invisible box over the original. We chose the honest overlay editor. The editor page says clearly: "Existing PDF content cannot be edited in-browser." That sentence is the point.

What we got wrong

Not everything worked on the first try. A few things took embarrassing amounts of time to figure out.

The coordinate system flip

PDF coordinates have their origin at the bottom-left of the page, with Y increasing upward. Browser canvas and CSS coordinates have their origin at the top-left, with Y increasing downward. Every element we place in the editor needs to be transformed between these systems on export.

The first version of the editor had signatures appearing at the bottom of the page when they should have been at the top, and vice versa. It took a genuinely embarrassing amount of time to spot the sign error. Two pages of code, one minus sign.

Font embedding

Standard PDF fonts (Helvetica, Times, Courier) don't need embedding — every PDF reader has them. Custom fonts do, and embedding a TrueType font into a PDF from JavaScript is not straightforward. For now, our editor supports the standard fonts. Custom font embedding is on the roadmap but not shipped, and we say so on the relevant pages.

Encryption that doesn't claim more than it delivers

The Protect PDF tool was the most honest thing we've had to write. pdf-lib doesn't expose a public API for encrypting an existing PDF in the version we use. So instead of claiming encryption we can't guarantee, the tool checks whether the API is available at runtime. If it is, we encrypt. If it isn't, we say so and offer a rasterization fallback (which removes text but isn't encryption).

It would have been easy to write a tool that adds a password prompt and calls it "protected". It would also be a lie. We chose the version that tells the truth about what it can and can't do.

OCR accuracy promises

The first version of the OCR page said "high accuracy on English documents." That's the kind of vague claim that sounds good and means nothing. We rewrote it to give specific numbers — around 95% on clean printed Hindi at 300 DPI, under 40% on handwriting — and a section on when OCR fails.

Users deserve to know when a tool won't work for their use case. Telling them upfront is better than letting them discover it after waiting five minutes for the OCR to run.

The honesty rule

Everything above comes down to one rule we settled on early: never claim a feature works unless it actually does.

That has real costs. It means writing "compression converts text to images" instead of "compress PDFs losslessly". It means the editor page says "you cannot edit existing text" instead of "professional PDF editor". It means the Protect tool has a fallback for when it genuinely can't encrypt.

It also means the tools are shorter — fewer features, but each one works. A tool that does one thing well is more useful than a tool that claims ten things and delivers three.

What's next

The full roadmap is on the About page, but the short version:

• Page reordering as a standalone tool. Currently you can achieve it via extract + merge, but a dedicated tool would be much more pleasant.
• Custom TTF fonts in the editor and text tools. This unlocks the ability to match the fonts already used in a PDF.
• Embedded image extraction. Currently we only render pages; extracting the actual embedded images is a different (and useful) operation.
• Better Hindi OCR. Tesseract's Hindi model has limits. We're watching for improvements and better models.

Everything we build continues to follow the same rule: no server, no uploads, no fake features.

A final note

DSPDF isn't trying to be the biggest PDF tool suite. It's trying to be a small, honest one — the kind of thing you can bookmark and use for years without worrying that a future version will start quietly uploading your files or gating features behind a subscription.

If that resonates, the tools are yours to use. If you find a bug or want a feature, see the Contact page. We read every message.