JWT Decoder

Paste a JSON Web Token and see exactly what is inside: header, payload and signature separated, every claim explained, expiry times as real dates. Signature verification included – all locally in your browser.

What a JSON Web Token is made of

A JWT is not a secret – it is a message with a proof of authenticity. It consists of three dot-separated parts: the header naming the signature algorithm, thepayload carrying the actual statements about the user (the claims), and thesignature. Header and payload are merely Base64url-encoded JSON – encoded, not encrypted. Anyone who gets hold of a token can read it. That is exactly what this decoder makes visible.

The only thing being protected is integrity: the signature is computed over the stringheader.payload. Change a single character in either part and the signature no longer matches. This is why passwords, keys or any other secrets never belong in a JWT payload.

Registered claims and what they mean

RFC 7519 defines a handful of claims with a fixed meaning: iss (issuer),sub (subject, usually the user ID), aud (audience), exp(expiration time), nbf (not before), iat (issued at) and jti(unique token ID). The time values are NumericDate numbers – seconds since 1 January 1970, which is hard to read as a bare integer. This tool therefore also shows them as a date and as a distance from now (“expires in 42 minutes”).

Everything beyond that is application-specific. OpenID Connect adds nonce,azp, auth_time and at_hash, OAuth 2.0 contributesscope. Claims such as roles, groups orpermissions are pure convention and mean something different in every system.

Verifying the signature: symmetric or asymmetric

Whether a token is genuine is decided solely by its signature – and that can only be checked with the matching key. The HS algorithms (HS256, HS384, HS512) use an HMAC with a shared secret: whoever can verify can also sign. With RS, PS,ES and EdDSA, the public key is enough to verify, while only the holder of the private key can sign. That is why identity providers publish their keys as a JWK set at /.well-known/jwks.json.

Verification here runs through your browser's Web Crypto API. As a key, the tool accepts a raw secret (UTF-8, Base64, Base64url or hex), a PEM in SPKI form (“BEGIN PUBLIC KEY”), a single JWK, or a complete JWK set – in the latter case the key matching the kid from the header is picked automatically.

Frequently asked questions

Is my token uploaded?
No. Decoding and signature verification happen entirely in your browser; there is no server that could receive anything. Neither token nor key is stored – the only thing remembered is whether you prefer times in UTC.

Does this “decrypt” a token?
No, and that is a common misconception. An ordinary JWT (more precisely: a JWS) is not encrypted at all, only encoded. Decoding it is therefore not an attack but the intended behaviour. Genuinely encrypted tokens exist as JWE – they have five parts instead of three and cannot be read without the recipient's private key.

What does alg: none mean?
That the token is unsigned. Historically this was the basis of an entire class of vulnerabilities: libraries accepted tokens where an attacker had simply set the algorithm to none and removed the signature. A verifying service should always pin the expected algorithm itself instead of taking it from the header.

The token is expired – does that make it invalid?
As far as the time claims go, yes. But it says nothing about authenticity: an expired token can carry a valid signature, and a fresh one a forged signature. This tool therefore keeps the two apart on purpose – “validity window” and “verify signature” are two separate statements.