What's New on KeyForge: JWT Decoder, Hash Identifier, and JSON Diff

KeyForge started as four tools: a GUID generator, an encrypt/decrypt utility, a password generator, and a JSON formatter. Over the last few weeks that list has grown, and a handful of the existing tools picked up features that weren't there before. This is a walkthrough of what changed, why each addition exists, and how to actually use it.

A brand new JWT Decoder

The biggest addition is a fifth tool: a JWT Decoder. Paste a JSON Web Token and it splits the three dot-separated segments, decodes the header and payload from base64url, and shows both as formatted JSON. No key is needed for that part: a JWT is encoded, not encrypted, so the header and payload are readable by anyone holding the token. The decoder also checks the payload for an expclaim and, if one is present, compares it against your device's clock to flag the token as expired or still valid.

The part that does need a key is signature verification, and the tool supports that too, for HS256 tokens specifically. Enter the HMAC secret the token was signed with and it recomputes the signature in-browser using the Web Crypto API, then compares it against the one in the token. Tokens signed with RS256, ES256, or another asymmetric algorithm are still decoded, since that part needs no key, but aren't verifiable here without adding public-key support, which isn't implemented yet.

This is the same reason the rest of KeyForge exists: a JWT often carries a session identifier or an internal claim you'd rather not paste into a random website's form. Decoding it locally means it never leaves your machine, whether you're debugging a failed login, checking what scopes an OAuth provider actually issued, or confirming a token was signed with the secret you expected before it ships to production.

Identify a hash from its shape alone

The Encrypt / Decrypt tool now has a hash identification mode below the main form. Paste a string you suspect is a hash and it guesses which algorithm produced it, based on length and format rather than trying to reverse it (hashes are one-way by design, so reversal isn't possible). A 32-character hex string comes back as a likely MD5 or NTLM hash. Forty characters suggests SHA-1. Sixty-four points to SHA-256. It also recognizes base64-encoded digests by their decoded byte length, and Unix crypt formats like $2a$ for bcrypt or $6$ for SHA-512 crypt by their prefix.

It's a guess, not a proof: several algorithms share the same output length, which is exactly why the tool lists every plausible match instead of picking one. Still, when you're staring at a string in a database dump or a config file with no idea what produced it, narrowing sixty possible hash algorithms down to two or three based on length alone saves real time.

Inspecting a UUID you didn't generate

The GUID Generator picked up the reverse operation: paste an existing UUID and it tells you the version, and for version 1 specifically, the timestamp encoded inside it. A v1 UUID embeds a 60-bit timestamp measured in 100-nanosecond intervals since October 15, 1582 (the date the Gregorian calendar took effect, which is the epoch the UUID spec settled on), so decoding it means extracting those bits and converting the result back to a normal date. That's useful for figuring out roughly when a record was created when a v1 UUID is the only timestamp you've got, or for confirming a UUID you were handed really is the version your system expects before you rely on it being sortable by creation time.

The generator also gained CSV and JSON export for bulk output. Generating fifty or a hundred UUIDs at once used to mean copying them out of a textarea; now there's a button that downloads them directly as a .csv or .jsonfile, which is a smaller thing but saves a step every time you're seeding test fixtures or building a spreadsheet.

Comparing two JSON values, and an editor that highlights syntax

The JSON Formatter now has a comparison mode: paste two JSON values and it reports exactly what was added, removed, or changed between them, down to the path of each difference (user.age, tags[1], and so on). This walks both values recursively rather than just diffing the raw text, so reordering an object's keys doesn't register as a change and a genuinely different array element does. It's the kind of check that's tedious to do by eye once a payload has more than a handful of fields, whether you're comparing two versions of an API response or checking what a config change actually altered.

Every JSON text box across the tool, input, output, and both comparison panes, also now highlights syntax as you type: keys, strings, numbers, and literals each render in a distinct color, and pressing Tab inserts a real tab instead of jumping focus to the next control. Small changes individually, but they add up to a text area that behaves more like an editor and less like a plain form field.

The theme running through all of it

None of these additions changed how KeyForge works under the hood: everything still runs in your browser, using the Web Crypto API for anything cryptographic, with no server-side processing step for any of it. A hash you're trying to identify, a token you're decoding, or two JSON payloads you're comparing never get sent anywhere, which matters more for some of these than others (a production JWT is not something you want to paste into a form on a site you don't control). Check the roadmap on the homepage for what's planned next.

← Back to KeyForge