Every "Free" PDF Editor Wants Your Resume First. I Got Tired of Uploading It.

Pranav — Mon, 17 Aug 2026 17:03:02 +0000

I needed to fix a typo on my resume last year — one line, wrong phone number — and it took longer than it should have because I refused to do the obvious thing: type "free pdf editor" into Google and use the first result.

Here's why. Every one of those tools works the same way. You drag your PDF into the browser, it gets uploaded to a server, something processes it, and a few seconds later you download the result. That's the entire model. And the file that just made that round trip was my resume — home address, phone number, employment history, sometimes references — sitting on a server operated by a company whose terms of service I definitely didn't read.

Most people don't think about this, because "upload" has become such an invisible verb online that it barely registers as a decision anymore. But it is one. And for a PDF specifically, it's a decision you're often making with your most sensitive documents: signed contracts, tax forms, medical records, your CV.

The watermark problem is the same problem in disguise

The other thing you'll notice, if you've used any of the big free PDF sites, is the watermark. Merge two files for free and you get a diagonal logo stamped across your output — or a hard cap of three files, or a "sign up to continue" wall after your second edit. iLovePDF, Smallpdf, Adobe's free tier — they all do some version of this, and it's not really a technical limitation. It's a business model: give away just enough to get you hooked, then monetize the friction.

The watermark and the upload are connected, even though they don't look related. Both come from the same underlying architecture: your file goes to a server, the server does the work, and now the server-owner controls the terms of getting your file back — watermark included, subscription optional. If the processing never leaves your device in the first place, there's no server-side gatekeeper to add a watermark or throttle you at all.

What I switched to

I ended up on ihatepdf.cv, which does the PDF editing directly in the browser using WebAssembly — meaning the "upload" step just doesn't exist. There's nowhere for the file to go, because nothing is sent anywhere. You open the PDF editor, click the typo, fix it, and download — and the whole thing happens on your own machine.

A few things stood out using it for actual tasks, not just the privacy pitch:

No watermark, ever — not a "pay to remove" watermark, just none, on any of the 46 tools.
It works with no internet after the first load — I've since used it on a flight to merge some contracts, which isn't something you can do with an upload-based tool.
No account, no email, no "sign up to download." You use the tool and you're done.
Redaction and a privacy scanner that checks a PDF for hidden metadata — author name, GPS coordinates, edit history — before you send it to someone. I didn't know PDFs quietly carried that stuff around until I ran a file through it.

Why this is worth thirty seconds of thought

I'm not going to pretend uploading a random PDF to a free tool is going to ruin your life. Most of the time, nothing bad happens — the file gets processed, deleted, and nobody looks at it. But "most of the time nothing bad happens" is also true of leaving your front door unlocked. It's not really an argument for doing it on purpose, especially when the alternative costs you nothing.

The next time you're about to drop a resume, a contract, or a scanned ID into a random "free PDF editor" tab, it's worth a beat of thought about where that file is actually going — and whether it needed to go anywhere at all. Increasingly, for basic PDF tasks, it doesn't have to.

If you want to try it yourself: ihatepdf.cv — free, no watermark, no upload, no signup. I'd genuinely like to hear if it handles your use case; drop a comment.

I Built a 46-Tool PDF Editor That Never Touches a Server. Here's the WASM Architecture Behind It.

Pranav — Mon, 17 Aug 2026 17:01:25 +0000

Every "free" PDF tool I've ever used works the same way: you upload your file to a server, a script on the other end does the actual work, and you download the result a few seconds later. That's fine until you remember what people actually put in PDFs — signed contracts, medical records, tax documents, resumes with home addresses on them — and realize you just handed all of it to a company you've never heard of, in exchange for a "merge" button.

That bothered me enough that I spent the last several months building ihatepdf.cv, a PDF toolkit with 46 tools — merge, split, compress, OCR, encrypt, redact, convert to and from almost every format, even a GST invoice generator — where the file never leaves the browser. No upload step exists in the architecture, because there's no server-side processing to upload to.

Here's what building that actually looked like.

The constraint that shaped everything

The moment you say "no server," you've ruled out the easy path for basically every PDF operation. Compression, OCR, format conversion — these are normally solved with a beefy backend running Ghostscript, Tesseract, or LibreOffice headless. None of that exists in a browser tab.

So the entire toolkit is built on WebAssembly modules doing the heavy lifting client-side, wrapped in a PWA shell so the app itself works offline after the first load. A few examples of how that split played out:

Compression — three presets (Light/Medium/Heavy) implemented by re-encoding embedded images and re-serializing the PDF object graph in-browser, rather than shelling out to Ghostscript.
OCR — Tesseract compiled to WASM, run entirely client-side against scanned pages to produce a searchable text layer.
Office format conversion (Word, Excel, PowerPoint ↔ PDF) — this is normally the hardest thing to do without a server, since it usually means Microsoft's own rendering engine. Getting formatting, merged cells, and embedded fonts to survive the round trip without a backend was the single most time-consuming part of the build.
AI features (chat-with-PDF, summarization) — the one place a network call is unavoidable, since on-device LLMs aren't practical yet for this. Everything else stays local.

The handwriting-to-PDF problem

The tool that took the most iteration was converting handwritten notes into a searchable PDF. My first few attempts ran OCR and dumped the recognized text back onto the page — and it wrecked any document with actual structure: tables, multi-column notes, forms. Text would get recognized correctly but placed in the wrong reading order, or a two-column page would get flattened into one garbled column.

I went through a few architectures before landing on the right one:

Tune Tesseract's page segmentation mode (PSM) per document type — no single PSM setting worked for both dense paragraphs and sparse tables.
Add line-grouping logic to reconstruct reading order from bounding boxes instead of trusting raw OCR output order.
Add gap-based column splitting to detect multi-column layouts before running line grouping.

All of that improved accuracy, but it was still fundamentally fragile — I was trying to reproduce the original layout from OCR output, which throws away information every time.

The fix was to stop trying to reconstruct the page at all. The tool now produces a "searchable scan": the original handwritten image stays exactly as-is as the visual layer, and the OCR'd text sits invisibly underneath it, positioned to match. You see your actual handwriting; Ctrl+F finds the words anyway. It's a much smaller claim architecturally — don't recreate the document, just make it searchable — and it's the version that actually holds up on messy real-world input.

Service workers are where PWAs go to die

The offline-first requirement meant getting a service worker right, which is its own genre of pain. The specific bug that cost me the most time was a TypeError thrown when the SW's cache lookup resolved to undefined — happening intermittently, only on certain navigation patterns, which made it miserable to reproduce. The fix ended up being a full rewrite of the fetch-handling logic to explicitly guard every cache read instead of assuming a Response would always come back. If you're building a PWA and haven't hit this yet, you will — write the defensive check before you need it.

Why this matters beyond the privacy pitch

"No upload" is usually pitched as a privacy feature, and it is one. But it's also just a product advantage that's easy to undersell:

It works on a plane. Once the PWA is cached, there's no network dependency for 45 of the 46 tools.
There's no file size ceiling imposed by a server timeout or upload limit — processing is bounded by the user's own device, not by what a backend is willing to accept.
The infra bill doesn't scale with usage. Every PDF operation is a cost on the user's CPU, not mine. That's a very different scaling story than a SaaS with a processing queue.

The tradeoff, to be honest about it: client-side WASM bundles are heavy, and shipping 46 tools' worth of processing code without tanking Core Web Vitals (especially LCP and TBT) has been an ongoing tuning problem, not a solved one.

If you're curious about the rest of the toolkit or want to see how a specific conversion holds up on your own file, it's live at ihatepdf.cv — genuinely free, no watermark, no signup, and your file really doesn't go anywhere. I've also got a running technical blog where I document architecture decisions like these in more depth.

Happy to go deeper on any part of this in the comments — the OCR layout problem in particular I could talk about for a while.

DEV Community: Pranav