Webp-Recast and PDF Squeeze both run entirely in the browser. That constraint made them simpler to build and easier to trust.
I kept needing to shrink an image before pushing it to a repo, or compress a PDF before emailing it. The free tools that come up first in search all want an upload, which means handing a client's unreleased design or someone's signed document to a server I know nothing about.
So I built two that do not. Webp-Recast converts and resizes images, PDF Squeeze compresses PDFs, and in both cases the file never leaves the machine it started on.
The constraint pays for itself
Once processing happens client-side, a whole category of work disappears. No upload endpoint, no temporary storage, no cleanup job for abandoned files, no per-file bandwidth cost, no privacy policy explaining what happens to user data because nothing is collected. The hosting bill for both tools is zero and stays zero no matter how many people use them.
- No server means no upload limit beyond the user's own memory
- No queue means results are instant, no polling for a job to finish
- Nothing to leak, because nothing is ever stored
- Works offline once loaded
Where it stops working
Client-side processing is bounded by the device. A very large PDF on a low-memory phone will struggle in a way a server never would, and heavier operations are limited by what browser APIs actually expose. That trade is worth it for the common case, which is one file, right now, that you would rather not hand to a stranger. When the job is genuinely heavy, that is when a server earns its keep.
Both are free, need no sign-up, and are open source. The pattern generalises further than I expected, and it is now the first thing I reach for whenever a tool's job is to transform a file rather than to remember one.