The PDF tool I avoided building for two months (and what finally made me sit down and do it)

I want to tell this the way it actually happened, not the cleaned up launch post version.

For about two months I kept seeing the same thing in my search console data. People landing on KuberAgent looking for "compress pdf" or "crop pdf online," staying for maybe four seconds, and leaving. Every single week. I'd notice it, feel a small pang of guilt, close the tab, and go work on something that felt more exciting instead, like the background remover.

My reasoning at the time was that PDF compression is a solved problem. Everyone has a version of it. It felt boring. Low priority. The kind of thing you build in a weekend once you're bored of everything else.

I was wrong about almost all of that, and it took actually sitting down to build it to find out why.

What changed my mind

A cousin of mine was applying for a government job. Deadline that night. The form capped uploads at 2MB and her scanned marksheet was sitting at 4.7. She spent close to forty minutes cropping the white space around the scan, convinced that trimming the margins would eventually shrink the file enough. It didn't move at all. By the time she called me, panicked, I realized the actual problem wasn't that she needed a better tool. It was that she didn't know cropping and compressing are two completely different operations, and honestly, most people don't.

That was the moment the "boring, solved" excuse stopped holding up. It wasn't solved. It was just misunderstood, by basically everyone, all the time.

Why I kept putting it off anyway

Once I actually opened the editor and started building, I understood the real reason I'd been avoiding it. It wasn't boring. It was just quietly hard in a way that doesn't show up until you're inside it.

Every other free PDF compressor online works the same way. Upload your file to a server, run it through something like Ghostscript, send it back. That's a completely fine approach if you don't care about a constraint I'd already committed to across the whole site, which is that nothing ever leaves the browser.

Doing this entirely client side meant re-encoding the images buried inside a PDF's structure using WASM, inside the browser's own memory, with no backend to hand the heavy lifting to. A 40MB scanned PDF with thirty image heavy pages will crash a mobile browser tab without much effort if you're not careful about releasing memory page by page instead of loading the whole document at once. I hit that wall more than once and had to rebuild the whole processing pipeline around it.

Then there was the mess of real world PDFs. In theory every PDF follows a spec. In practice, files coming out of old scanners, WhatsApp forwards, and random online converters people used years ago all carry slightly broken internal structures. I ended up collecting a small graveyard of genuinely ugly PDFs from friends just so I had something realistic to test against, because the clean sample files I started with told me nothing useful.

And the crop tool, which I assumed would be the easy half of this project, turned out to be its own trap. The actual operation is simple, you're just adjusting a boundary called the CropBox. But building a drag to select box that behaves properly on both mouse and touch, that stays accurate across a multi page document, and that lets someone set a different crop for every single page without the state quietly breaking somewhere, ate more days than the compression engine did.

The decision I keep circling back to

More than once, usually late at night while chasing a memory leak, I seriously considered just doing this the normal way. Upload the file, process it on a server, send it back. It would have shipped in a fraction of the time.

But the whole reason someone ends up needing a tool like this is often that the file is something they'd rather not hand to a stranger's server in the first place. A signed contract. A salary slip. An ID scan. If I quietly break that promise the moment a tool gets technically inconvenient, then the promise never meant anything to begin with.

So it stayed in the browser. It took longer than I'm comfortable admitting. I still think it was the right call, though I'll be honest that I don't fully know yet whether people actually notice or care about that constraint, or if they just use the tool and move on without thinking about where the file went.

Where it ended up

Compress PDF and Crop PDF are both live now, free, no signup, no watermark, both running entirely offline once the page loads.

If anyone here has built something similar, PDF, image, or audio processing that runs client side, I'd genuinely like to compare notes on how you handled memory management. That was the part that humbled me the most. And if either tool breaks on some strange file you've got lying around, tell me. My graveyard of ugly test PDFs is never quite big enough.