Tech
JWT Decoder
Decode any JSON Web Token into its header, payload, and signature. See standard claims (iss, sub, aud, exp, iat, nbf), expiration status, and security warnings. Decodes only, does not verify the signature.
Decode a JWT
Decoding runs locally in your browser. The token is never sent to a server.
Paste a JWT above to see its header, payload, and standard claims.
Frequently Asked Questions about the JWT Decoder
What is the structure of a JWT?
A JSON Web Token is three base64url-encoded segments joined by dots: header.payload.signature. The header is a small JSON object that names the signing algorithm (alg) and token type (typ). The payload is a JSON object of claims (iss, sub, aud, exp, iat, nbf, plus any custom fields). The signature is the cryptographic proof that ties the header and payload to a key the issuer holds. Decoding any segment is just a base64url decode and a JSON parse; verifying the signature is a separate step that needs the issuer's secret or public key.
Is a JWT encrypted? Can anyone read the payload?
Plain JWTs (JWS, the signed kind almost everyone uses) are not encrypted. The payload is base64url-encoded, which is reversible by anyone with the token, so all claims are public. The signature only protects integrity: it stops an attacker from changing the payload without invalidating the token, but it does not hide what the payload says. Never put passwords, full credit card numbers, or other secrets in a JWT. If you need confidentiality on top of integrity, use JWE (the encrypted variant) or wrap the token in TLS plus a server-side session.
Why does this tool decode without verifying the signature?
Verification needs the issuer's secret (for HS256) or public key (for RS256, ES256, EdDSA), and a browser-side decoder has access to neither. Sending the secret to a third-party tool would leak it; fetching the issuer's JWKS for every paste would be slow and add a network dependency the user did not ask for. So this decoder shows you exactly what is inside the token and flags suspicious algorithms or expired tokens, but leaves the cryptographic check to your backend, where the key already lives. Treat any unverified JWT as user input, never as authority.
What are the standard JWT claims (iss, sub, aud, exp, iat, nbf)?
RFC 7519 defines seven registered claims. iss (issuer) names who minted the token. sub (subject) names the principal the token is about, usually a user ID. aud (audience) names who the token is for; servers must reject a token whose aud does not match their own identifier. exp (expiration) is a Unix-seconds timestamp after which the token is invalid. nbf (not before) is the earliest time the token may be used. iat (issued at) is when the token was minted, useful for audit logs and freshness checks. jti (JWT ID) is a unique identifier per token, used for revocation lists.
What is the alg:none vulnerability?
The JWT spec includes a no-signature mode where alg is set to "none" and the signature segment is empty. A broken validator that trusts the header's alg field can be tricked by an attacker who strips the signature, switches alg to "none", and resends the token, since there is now no signature to check. Compliant libraries reject alg "none" unless the application explicitly opts in, and production code should pin the expected algorithm (such as RS256) rather than trusting whatever the header claims. If this decoder flags an alg-none token, treat it as untrusted: a real JWT producer almost never emits one.