JWT decoder
Paste a token to see what it contains and when it expires. If you have the key, you can check the signature too.
Decoding happens in your browser. Nothing is sent.
Validity
…
Decoded, not verified: anyone can create a token with these contents. Enter the key below to check the signature.
Header
{
"alg": "HS256",
"typ": "JWT"
}Payload
{
"iss": "https://example.com",
"sub": "1234567890",
"aud": "quaestio",
"name": "Ada Lovelace",
"iat": 1757000000,
"nbf": 1757000000,
"exp": 4102444800,
"jti": "4f1c2a9e"
}Fields and claims
- algsignature algorithm
- HS256
- typtoken type
- JWT
- ississuer
- https://example.com
- subsubject, usually the user ID
- 1234567890
- audaudience the token is intended for
- quaestio
- expexpiration time
- 4102444800
- nbfnot before
- 1757000000
- iatissued at
- 1757000000
- jtiunique token ID
- 4f1c2a9e
- Signature
- 32 bytes
Verify the signature
The key is only used in your browser and is not stored.
How it works
A JSON Web Token (JWT, RFC 7519) has three parts separated by dots: header, payload and signature. The header and payload are JSON encoded with base64url, a variant of base64 that uses - and _ instead of + and / and leaves out the padding. Anyone can read the contents; they are not encrypted.
The header gives the algorithm (alg) and often the type (typ) and the key ID (kid). The payload holds claims, statements about the user or session. The standard registers seven: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at) and jti (JWT ID). Any other claims are up to the issuer.
The times in exp, nbf and iat are seconds since 1 January 1970 UTC. A token must not be accepted on or after its exp time, nor before its nbf time. The decoder compares them with the clock on your device, so a clock that is wrong gives the wrong status.
Decoding is not verification. The signature shows that the token was issued by someone holding the key and that the contents have not been changed, but that can only be checked with the key. HS256, HS384 and HS512 use a shared secret (HMAC). RS and PS use RSA, ES uses elliptic curves (ECDSA with P-256, P-384 or P-521) and EdDSA uses Ed25519; these are checked with the public key as PEM or JWK, which issuers often publish as a JWK Set.
A token with alg none has no signature and must never be accepted by a server. Several well-known vulnerabilities came from libraries that accepted none, or that let an attacker swap RS256 for HS256 and sign with the public key as the secret.
A token often works as a key to an account. Everything here happens in your browser with its built-in cryptography (WebCrypto), and neither the token, the secret nor the key is sent anywhere. Even so, never paste a live token or secret into a site you do not trust, and never paste a private key: verification only needs the public one.