How I built image and PDF tools that run in your browser, so the files stay on your device

I didn't set out to build "another online tools site."

I set out to stop a very specific kind of afternoon. In India, during admission and exam season, a school office or cyber café often gets one sheet with many photos and signatures on it. Someone then sits in a photo editor, cuts each one out, resizes it to 20 KB or 50 KB, and names the files. It takes ages, and the files are other people's identity documents.

That is how Crop Desk started: a page where you can open that sheet in the browser, mark the boxes, and download the cropped files. The site is at usecropdesk.com. It is free, you don't need an account, and it is an independent India-based project. It is not affiliated with any exam board or government department.

The rule I didn't want to break

Once you are dealing with ID photos, signatures, and PDFs of forms, uploading those files to a server "just to crop them" feels like the wrong default.

So the product rule became: most tools should run in the browser. The file is chosen on the user's device, processed there, and downloaded from there. It should not have to sit on my server for the tool to do its job.

"Most tools" is the honest wording — I won't pretend every current and future feature is identical. The usual photo and document jobs are designed to stay on the device, and you can use them without signing up. An optional free account exists only to save your own work, such as typing-test history or a resume draft.

What "in the browser" actually means for the user

The flow is ordinary: open the page, pick a file, adjust the crop or the size, download the result. There is no "upload and wait for our server" step, because the work is not supposed to leave the device. In practice that uses what the browser already gives you — the file picker, in-memory image and PDF data, an on-screen preview, and a local download.

The trade-offs are ordinary too. You need a reasonably modern browser, and a network connection to load the page. A very large file can strain an older phone. The site can also be installed as a Windows app from Chrome or Edge, or added to an iPhone home screen from Safari — that is the same website, in its own window.

The tools that grew out of the first one

Once the bulk cropper existed, the next requests were predictable, because they come from the same forms.

People needed to hit a 20 KB, 50 KB, 100 KB or 200 KB cap without destroying the face or the signature. A generic "compress this image" button is not enough. The preview has to be good enough that you can see whether a form is likely to reject the file.

They needed passport-size photos: the usual India sizes, and also a dedicated 2×2 inch US passport photo page with a 4×6 print sheet.

They needed everyday PDF jobs in the same place: compress (including common KB targets), merge, sign, watermark, and a few conversions such as Word to PDF.

And, because this is India, they needed Hindi typing (Kruti Dev 010 and Mangal/Inscript) and a Kruti Dev ↔ Unicode converter.

Later I added only adjacent jobs: a resume builder with PDF download, a document scanner that flattens a phone photo, a signature background remover, a photo-and-signature joiner, HEIC to JPG, and image metadata removal.

What I still tell people

If an exam form says "photo under 20 KB, 3.5 × 4.5 cm, JPEG," the official notification is still the source of truth. I publish plain-language guides, and I try to keep them careful, but requirements change. I am not an exam body, and I don't want the site to sound like one.

The other thing I still want to improve is first-visit clarity. If someone lands on the homepage, can they tell — without reading a privacy policy — that the file stays on their device? That matters more to me than adding another tool.

If you try Crop Desk and something in that flow is unclear, I would rather hear that than a compliment.

This post was written with AI assistance and reviewed by the maker.