Developer Tools

The tools

Utilities chosen for the same reason: each one is something developers paste into a random web page several times a week, and each one handles input that probably shouldn't be sent to a stranger's server.

Why client-side matters

These tools deal with data that's often sensitive — JWTs can carry session tokens, OAuth scopes, and PII; Base64 frequently wraps secrets; hashes are sometimes fed real passwords (please don't). Sending any of that to an unknown server's API is a habit worth breaking. Every utility here runs entirely client-side: no fetch, no upload, no logging, no storage.

Verify it by checking your browser's network tab while you use the tools — you'll see nothing. The JWT decoder is plain Base64URL parsing and JSON; the Base64 converter is built on the browser's own TextEncoder / atob / btoa; the hash generator calls crypto.subtle.digest, which is implemented natively by the browser. The output appears in your tab the moment you stop typing, and nothing crosses the wire to do it.

When to use each

These tools cover distinct daily problems. A quick guide on what to reach for:

• JWT Decoder — debugging an authentication flow, inspecting OAuth or OIDC tokens, checking expiration (exp) and issued-at (iat) timestamps, confirming the iss and aud match what your server expects, or just seeing what a third-party API actually packed into the token it gave you.
• Base64 — decoding data: URLs, encoding binary for JSON or email or SMTP transport, working with Authorization: Basic headers, and the URL-safe variants used in tokens, webhooks, and signed query strings. Also handy for reading whatever your CI/CD system pasted into an env var.
• Hash Generator — file integrity checksums (MD5 and SHA-256 are the two you'll see in the wild), cache-busting filenames, debugging webhook signatures (GitHub, Stripe, Twilio all sign with HMAC-SHA-256), and producing content-addressed storage IDs.

None of these are exotic — they're things you've done a hundred times. The point of having a dedicated page for them isn't novelty, it's the small relief of opening a tab, pasting, and getting an answer without first navigating around a registration wall or wondering whether the site is logging your input.

Hash algorithms at a glance

The Hash Generator supports five algorithms. Which one to reach for depends on whether you need integrity (any of them will do) or security (only the current ones):

Anatomy of a JWT

A JSON Web Token is three Base64URL-encoded segments joined by dots: header.payload.signature. The header names the signing algorithm (alg) and token type (typ), and often a key id (kid) telling the verifier which key to use. The payload carries the claims. The signature covers the first two segments joined by a dot — which is why changing either one invalidates it.

The first thing worth internalising is that the payload is not encrypted. It is encoded, not protected. Anyone holding the token can read every claim in it, which is what the JWT Decoder does — no key required. Signing proves the token hasn't been altered and came from someone holding the key; it does nothing to hide the contents. Secrets do not belong in a JWT payload. (The encrypted variant is JWE, a separate specification, and it looks different — five segments rather than three.)

RFC 7519 registers a small set of claims. Everything else is application-defined:

The timestamp claims are NumericDate values — seconds since the Unix epoch, not milliseconds. Passing a JavaScript Date.now() straight into exp produces a token that expires roughly 50,000 years from now, which is a bug that ships more often than it should.

The second thing to internalise: decoding is not verifying. Our decoder deliberately stops at decoding — it reads the segments and shows you what's inside, and it does not check the signature. That check belongs on your server, with your key, and it has two classic failure modes. The first is the alg: none case: the specification defines an unsecured token with no signature, and a library that honours the header's own claim about which algorithm to use will happily accept a forged token that says it needs no checking. The second is algorithm confusion, where a token signed with HS256 is presented to a verifier expecting RS256, and the verifier uses its public key as the HMAC secret — a value the attacker also has, since it's public. In both cases the fix is the same: the verifier decides the algorithm, never the token.

Base64 in practice

Base64 maps every three bytes onto four printable characters, so encoded output is about a third larger than its input. That is the entire trade: you spend size to get a value that survives channels which only reliably carry text, such as JSON string fields, email bodies, and HTTP headers. It is not encryption and not compression — the Base64 converter reverses any of it instantly, and so can anyone else.

Two alphabets are in circulation, both from RFC 4648. The standard one ends with + and /; the URL-safe one substitutes - and _ so the result survives a query string or a path segment without further escaping. Tokens, webhook signatures, and signed URLs generally use the URL-safe form — including the JWT segments above. Feeding a URL-safe string to a decoder expecting the standard alphabet is a common source of "invalid character" errors, which is why the converter offers both.

Padding is the other reliable trip hazard. Standard encoding pads with = until the length is a multiple of four; URL-safe usage frequently strips it, since the padding carries no information and = is awkward in URLs. Some decoders require it, some restore it themselves, and some reject stripped input outright. If a string fails to decode and its length isn't a multiple of four, missing padding is the first thing to check.

In the browser specifically, atob and btoa operate on binary strings where every character must be in the 0–255 range. Hand them text containing an emoji or an accented character and they throw, or silently mangle it. Correct handling routes through TextEncoder and TextDecoder so the string becomes UTF-8 bytes first — which is what this converter does, and why non-ASCII input round-trips here when it breaks in a one-line console snippet.

One last note on Authorization: Basic. Those credentials are Base64 of user:password, and the encoding provides no protection whatsoever — it exists so that colons and non-ASCII characters survive the header. The security comes entirely from the connection being TLS. Decoding one in the converter to see the plaintext credentials is a fast way to make that point to anyone who thinks otherwise.

Frequently asked

"Why aren't there more tools here?"

Quality bar. There's no shortage of developer-utility sites that ship every conceivable converter, and most of them either bury the useful ones under ads or wrap them in tracking. The tools on this hub are the ones that meet the same standard as the rest of Network Lookup — accurate, ad-light, and entirely client-side. Adding more only when each one clears that bar.

"Will more be added?"

Likely yes. The shortlist of candidates: a JSON formatter and validator, a URL encoder/decoder (with the encodeURIComponent vs encodeURI distinction handled correctly), a regex tester with named groups and flag toggles, a UUID generator (v4 and v7), and possibly a timestamp converter that handles the half-dozen common formats. Each will follow the same rule: all in the browser, no telemetry, no upload. If there's a utility you keep wishing existed, the contact page is the place to ask.

"Why not just use browser DevTools, Postman, or a CLI?"

Fine if those are at hand. Chrome DevTools has a console where JSON.parse(atob(token.split('.')[1])) will decode the payload of a JWT in one line. Postman, Insomnia, and Bruno all decode JWTs in their auth tabs. openssl dgst -sha256 hashes a file faster than any web page can. These tools exist for the case where none of that is already open — you're reading a Slack thread, an email, a doc, a webhook log; you want to know what's in the blob in front of you; opening a terminal or a paid app for one paste feels like overkill. That's the niche: a quick tab, a quick paste, a quick answer.

Learn more

Companion hubs and posts that pair well with these utilities.