Every time I needed to quickly decode a JWT, format some JSON, or generate a UUID, I ended up on some tool site that either wanted me to sign up, buried the actual tool under three ad units, or — worse — silently sent whatever I pasted in to a server I had no reason to trust. For a lot of these tasks (hashing a password, decoding a token, checking a cert), that's not just annoying, it's a real thing to think twice about.
So I built Encoder.guru — a suite of developer tools that runs entirely client-side. No backend, no accounts, nothing you type or upload ever leaves your device. You can open dev tools and watch the Network tab to verify that yourself.
What's in it
84 tools across 11 categories at this point: JSON & text, encoding, hashing & security, image, PDF, CSS generators, code tools, text tools, color tools, and web/SEO utilities. A few I'm most happy with:
JWT Builder & Verifier — builds, signs, and verifies JSON Web Tokens with HMAC, entirely in-browser via the Web Crypto API.
AES Encrypt/Decrypt — AES-256-GCM encryption using crypto.subtle, no third-party crypto library needed.
SSL Certificate Decoder — paste a PEM cert, see every field decoded, no server round-trip.
JSON Studio — an all-in-one JSON workspace: format, validate, JSONPath queries, YAML/CSV conversion, diffing, flattening, and TypeScript type generation, all in one page.
Mock JSON Data Generator — define a schema, get realistic fake data with 24+ field types, useful for populating test fixtures without hitting an API.
CIDR Subnet Calculator — network address, broadcast, host range from any IPv4 CIDR block, for the moments ipcalc isn't installed.
Plus the usual suspects: Base64, all the SHA variants, regex tester, timestamp converter, PDF merge/split/compress, image resize/convert — the stuff you reach for a few times a week and shouldn't need to think hard about.
Why "runs in your browser" was the actual hard part
It's easy to say "no backend" — it's a different thing to make every tool actually work well without one. A few examples of what that meant in practice:
Hashing and encryption use the native Web Crypto API rather than pulling in a JS crypto library, which keeps the bundle small and the implementation auditable.
PDF tools run against pdf-lib and pdfjs-dist client-side — merging, splitting, and compressing PDFs entirely in the tab.
Image tools lean on Canvas / OffscreenCanvas so resizing and format conversion don't block the UI thread.
The whole thing is installable as a PWA with a service worker, so once you've opened a tool it keeps working offline.
No React, no build step, no framework — just modular vanilla HTML/CSS/JS per tool, which turned out to be the right call for something this size: fast to load, easy to keep consistent, and there's no bundler to fight with when I want to ship a new tool in an afternoon.
What's next
This is genuinely early — I'm actively adding tools and would rather build the ones people actually want than guess. If there's a tool you find yourself needing that isn't there, or something on the site that's rough around the edges, I'd like to hear about it.
Try it at https://encoder.guru — and if you have five minutes, I'd appreciate any feedback in the comments, good or bad.
Top comments (2)
Going vanilla with no build step for something this size is the choice I'd want to hear more about. Most people would reach for React the second they hit 84 tools, and you'd expect it to turn into spaghetti, but a separate module per tool actually sounds like it scales better than a shared component tree here. Since the whole pitch is "watch the Network tab, nothing leaves your device," have you thought about adding a Content Security Policy that blocks outbound connections outright? That way trust doesn't rest on the user remembering to check, the browser just refuses to phone home even if a dependency later tried to.
I've also had issues with online tools tracking usage, how did you handle security and data validation for these browser-based tools? I'd love to swap ideas on this.