JWT Decoder

A JSON Web Token (JWT, RFC 7519) is three base64url strings joined by dots: a header naming the signing algorithm, a payload of claims such as the user ID and expiry, and a signature. This decoder turns the first two back into readable JSON, lists each claim with its standard meaning, converts the iat, nbf and exp timestamps into dates, and says whether the token is inside its time window by your device clock. Paste a key and it also checks the signature — HS256/384/512 with a shared secret; RS, PS and ES 256/384/512 and EdDSA with a PEM public key, a JWK or a whole JWK Set, where it picks the key by the token’s kid. It is useful when an API returns 401, when you need to see which scopes or roles a token carries, or when you want to know exactly when a session expires.

1. Paste the token. A leading “Bearer ” from an Authorization header is removed for you.
2. Read the status: expired, not valid yet, within its time window, or no expiry.
3. Check the time claims, shown as dates in your time zone with the raw numbers beside them.
4. Switch between the claims table and raw JSON, and copy the header or payload.
5. To check the signature, paste the secret, the PEM public key or the issuer’s JWK Set (its /.well-known/jwks.json) under “Verify signature”. The result updates as you type.
6. Press “Try an example” to see a sample token if you don’t have one to hand.
7. To test your own verifier or API, open “Create a test token”, choose an algorithm, and sign — HS tokens with a secret you type, the others with a key pair made in your browser whose public key you can copy.

• Without a key it can’t tell you a token is genuine: anyone can write any claims, so a decoded payload alone proves nothing. A verified signature proves the key signed it — whether your server should accept it also depends on exp, nbf, iss and aud, which your server must check.
• The algorithm comes from the token’s header, but must match the kind of key: a public key is never used as an HMAC secret (the algorithm-confusion attack), and alg “none” is never valid.
• It does not fetch a JWK Set from a URL — paste its contents. EdDSA needs a recent browser; older ones say so rather than guessing.
• Encrypted tokens (JWE, five parts) can’t be read without the key; the decoder says so rather than showing garbage.
• The expiry status uses your device clock, which may be wrong. Servers also allow some clock skew.
• Nested or compressed payloads are shown as they are; the decoder doesn’t unwrap them.
• Decoding is plain base64url and JSON parsing in your browser, and verification uses your browser’s built-in WebCrypto. The token and the key are never sent to ToolsDev or anyone else, and neither is saved. Even so, a JWT is often a live credential: anyone who has it can act as you until it expires. Prefer test tokens, and never paste production tokens or secrets into any website — including this one. Verifying an RS/PS/ES/EdDSA token needs only the public key; the tool refuses a private key rather than use it.

The decoding happens entirely in your browser and nothing is transmitted, which you can confirm in your browser’s network tab. The bigger risk is the habit: a token copied into many sites can leak. Use expired or test tokens where you can.

Paste the key under “Verify signature”. For HS256 that is the shared secret (tick “Secret is base64” if your library stores it that way); for RS256, ES256 and the rest it is the issuer’s public key, as PEM or as a JWK. Most identity providers publish their keys at /.well-known/jwks.json — paste that whole document and the tool uses the key whose kid matches the token.

A mismatch between the algorithm and the key — an RSA key for an HS256 token, an EC key for RS256 — is a configuration mistake, not a bad signature, and treating it as one hides the real problem. It also refuses private keys and certificates and tells you what to paste instead.

They are Unix timestamps in seconds. iat is when the token was issued, nbf is the earliest time it may be used, and exp is when it stops being accepted.

An alg of none means the token has no signature. Libraries have had vulnerabilities that accepted such tokens, so a server should always reject them.

Each part of a JWT is base64url-encoded JSON, so its contents are readable by anyone. A JWT adds a structure and a signature that lets a server detect tampering — it does not hide the data.

Yes — open “Create a test token” under the decoder. HS256, HS384 and HS512 are signed with a secret you type. RS256, PS256, ES256, ES384 and EdDSA are signed with a key pair created in your browser for that one token; you get the public key as PEM and JWK to test a verifier, and the private key is never shown or kept. Use it for development only: a real system should mint its own tokens with its own keys.