I kept ending up on the same kind of website. I needed a quick JSON formatter or a YAML validator, I searched for one, and I landed on a page buried in ads that took four seconds to load and asked me to accept cookies twice. The tool itself was fine. Everything around it was miserable.
So over a few months I built my own. 50 tools, all free, all running fully in the browser. No backend, no accounts, no tracking. This is what I learned.
The one rule: everything runs client-side
I gave myself a single constraint at the start. Every tool has to work without a server. You paste your data, the work happens in your browser, nothing gets sent anywhere.
This was partly a privacy decision. When you use my JSON formatter, your JSON never leaves your machine. There is no server to log it because there is no server at all. For developers pasting in tokens, config, or API responses, that matters.
But the constraint also made the whole project possible. No backend means no hosting bill, no database to secure, no API keys to rotate, no server to keep alive. The entire site is static files on GitHub Pages. It costs nothing to run and it will keep working whether one person uses it or a thousand.
What client-side actually handles
More than I expected. Modern browser APIs are strong enough that most developer tools do not need a server at all.
Hashing was the surprise. The Web Crypto API does SHA-256 and SHA-512 natively, so my hash generator is a few lines calling crypto.subtle.digest. No library needed.
UUID generation is one call to crypto.randomUUID. Base64 is built in through btoa and atob. The clipboard, file downloads, image resizing through canvas, all native. My image compressor resizes and recompresses photos using a canvas element and never uploads a thing.
For the few things the browser cannot do alone I pulled in one small library. YAML parsing uses js-yaml. QR codes use a tiny generator library. That is it for dependencies across all 50 tools.
The parts that fought back
QR codes took three tries. The first two libraries I picked had broken or moved CDN builds, and I spent an evening watching the browser console throw 404s at me before I found one that actually loaded and had a sane API. Lesson learned: pin the version, do not trust the latest tag.
Client-side image compression is fiddly. Canvas will happily hand you a PNG that is larger than the original if you are not careful, because PNG is lossless and re-encoding adds overhead. I had to detect that case and tell the user when their file was already optimised rather than pretend I saved them space.
Why no framework
The whole thing is plain HTML, CSS, and vanilla JavaScript. One HTML file per tool. No build step, no npm install, no bundler.
For a project like this that was the right call. Each tool is self-contained and small. If I want to fix the regex tester I open one file, change it, and push. There is no toolchain between me and the code. In a few years when some framework has moved on, these files will still open and run exactly as they do today.
Some tools I use myself
The YAML validator is the one I open most, usually to check a Kubernetes manifest before applying it. It validates the syntax and shows the parsed JSON so I can confirm the structure.
The SQL formatter cleans up the one-line queries that come out of application logs.
The diff checker and regex tester get daily use too.
All 50 are at aftabkh4n.github.io and the full source is on GitHub.
Would I do it again
Probably yes. The no-server rule sounded restrictive when I started and it ended up being the thing that kept the project alive. Simple code, zero hosting cost, and a privacy story I do not have to lie about.
If you build small utilities, try the browser-only version first. You can do more without a backend than you would guess. Worst case you hit a wall and add a server later, but I never did.
Top comments (0)