CalConverters

JWT Decoder & Verifier

Paste a JSON Web Token to decode its header and payload and read the claims, then optionally verify the signature. Everything runs locally — your token and keys never leave your device.

Files never leave your device

Paste a token above to decode its header and claims. Once decoded, a signature-verification panel with a secret or public-key field appears below.

What This Tool Does

This tool decodes a JSON Web Token (JWT) so you can read its header and payload without needing any key, and optionally verifies its signature if you supply the matching secret or public key. Paste a token, and you immediately see the decoded header, the claims inside the payload, and badges for whether it's expired or not yet valid — all computed from your device's own clock.

Everything runs locally through WebAssembly. There's no server involved in decoding or verifying, which matters because a JWT often carries session or identity data you wouldn't want passing through a third party's backend just to inspect it.

Anatomy of a Token

A JWT is three base64url-encoded segments joined by dots: header, payload, and signature — written as header.payload.signature. The header names the signing algorithm and token type; the payload holds the claims (things like the subject, an expiration time, or custom application data); the signature is the part that a verifier checks to confirm the first two segments haven't been altered.

// Decoded payload, for example
{
  "sub": "1234567890",
  "name": "Ada Lovelace",
  "exp": 1735689600
}
Tip: Decoding doesn't require a key because the header and payload are only encoded, not encrypted — anyone with the token text can read them. That's exactly why a decoded-but-unverified token shouldn't be trusted for anything security-sensitive: reading claims and confirming they're genuine are two different operations.

Decoding vs Verifying

These are separate steps, and the distinction matters. Decoding turns the base64url header and payload back into readable JSON — no key needed, and it works on any well-formed token, genuine or forged. Verifying recomputes the signature using a secret (HS256) or checks it against a public key (RS256, ES256) and confirms it matches what's attached to the token. Only a passing verification tells you the token was actually issued by whoever holds that key and hasn't been tampered with since.

Choosing an Algorithm

AlgorithmKey typeHow verification works
HS256Shared secret (HMAC)The same secret that signed the token is used to recompute the signature — both issuer and verifier must hold it
RS256RSA key pairThe issuer signs with a private key; you verify with the corresponding public key, which is safe to share
ES256Elliptic-curve key pair (P-256)Same public/private split as RS256, using ECDSA over the P-256 curve for a smaller signature

Use whichever algorithm the token was actually issued with — verification only succeeds against the correct key for that specific algorithm, not any key you happen to have.

Why alg: none Is Rejected

A small number of JWT libraries have historically treated the none algorithm as "valid, no signature required," which means anyone can construct a token with any claims they like and have it accepted as genuine — a well-documented class of real-world JWT vulnerabilities. This tool always treats alg: none as a failed verification rather than a pass, so pasting an unsigned token here never produces a misleading "valid" result.

Your Token Never Leaves Your Device

The token text, along with any secret or public key you enter to verify it, is processed entirely inside a WebAssembly module running in your browser tab. Nothing is uploaded, logged, or sent to a server — closing the tab clears everything, since there was never a network request carrying your token in the first place.

If you also need to set up two-factor authentication, see the TOTP generator & setup. If you need a fresh key pair to sign tokens with RS256 or ES256 elsewhere, see the Key pair generator — both run on-device the same way this tool does.

Frequently asked questions

Is my token sent anywhere?
No. Decoding and verifying both happen locally in your browser using WebAssembly — the token you paste, along with any secret or public key you provide for verification, never leaves your device or touches a network request.
What algorithms are supported for verification?
HS256 (a shared secret, using HMAC), and RS256 and ES256 (public-key signatures, using RSA and ECDSA respectively). Pick the algorithm your token was issued with, then supply the matching secret or public key.
Why does verify need a key or secret at all?
The signature is a mathematical proof that only someone holding the correct secret or private key could have produced. Verifying it means recomputing that proof: for HS256 the tool needs the same shared secret the issuer used, and for RS256 or ES256 it needs the issuer's public key. Without the right key, there's no way to distinguish a genuine token from a forged one.
Can I edit or sign a token with this tool?
No — this tool only decodes and verifies existing tokens; it doesn't create or re-sign one. That's intentional: a tool that lets you edit claims and re-sign with an arbitrary key is a very different (and riskier) thing than one that reads and checks tokens you already have.
Why did this tool reject my token with alg none?
The `none` algorithm means "no signature at all" — historically some libraries would accept it and treat the token as valid without checking anything, which lets an attacker forge any claims they want. This tool always rejects `alg: none` rather than treating it as a pass, so you never get a false sense of security from an unsigned token.
What's the difference between decoding and verifying?
Decoding just reads the header and payload — they're base64url-encoded, not encrypted or hidden, so anyone can decode a token without any key at all. Verifying is a separate step that checks the signature against a secret or public key to confirm the token wasn't tampered with and really was issued by whoever holds that key. Decoded claims you haven't verified aren't proof of anything.
The tool shows an expired badge — does that mean the signature is invalid?
No, they're independent checks. The expired badge is based on reading the `exp` claim and comparing it to your device's clock, which works even without a key. Signature validity is a separate check that requires the secret or public key. A token can be correctly signed and still expired, or unsigned/tampered and still carry an `exp` claim that hasn't passed yet — check both before trusting a token.