How to use the JWT Decoder
- Paste a JWT token (it starts with
eyJ) into the input box. - Click Decode to read the header, payload, and signature.
- The expiry time (
expclaim) is shown in a human-readable format if present.
What is a JWT?
A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519. It consists of three Base64url-encoded parts separated by dots:
- Header: declares the algorithm used to sign the token (
alg) and the token type (typ: "JWT") - Payload: contains claims: registered claims (
iss,sub,aud,exp,iat) plus any custom claims your application adds - Signature: the result of signing
base64url(header).base64url(payload)with the algorithm specified in the header
Common JWT claims
| Claim | Full name | Meaning |
|---|---|---|
iss | Issuer | Who created the token (e.g. your auth server URL) |
sub | Subject | User or entity the token refers to (usually user ID) |
aud | Audience | Intended recipient (e.g. your API's URL) |
exp | Expiration | Unix timestamp after which the token is invalid |
iat | Issued at | Unix timestamp when the token was created |
nbf | Not before | Token is not valid before this timestamp |
jti | JWT ID | Unique identifier to prevent token replay |
JWT vs session cookies
Traditional sessions store user state on the server; a session ID cookie is sent with each request. JWTs store state in the token itself, making them stateless: your server does not need to look up the session in a database. This makes JWTs attractive for microservices and distributed systems, but also means a valid token stays valid until expiry even after logout (unless you maintain a revocation list).
Security note
This tool decodes the token locally in your browser, it does not validate the signature. Decoded payload claims are not trustworthy without server-side signature verification. Never paste tokens that grant access to production systems into any online tool.
UK GDPR compliance and NCSC algorithm guidance
JWT tokens that carry user-identifying data (user ID, email, roles) are personal data under UK GDPR. Two practical consequences for developers:
- Token lifetime: The ICO (Information Commissioner's Office) applies the data minimisation principle. Use the shortest effective token lifetime. Short-lived access tokens (15-60 minutes) combined with refresh tokens are the recommended pattern.
- Data in the payload: The JWT payload is Base64-encoded, not encrypted. Any proxy, CDN, or application log can read it. Never store sensitive data (NHS number, bank details, passwords) in a JWT payload.
The NCSC (National Cyber Security Centre) recommends RS256 (RSA + SHA-256) or ES256 (ECDSA P-256) for production JWT signing. Explicitly reject tokens with "alg": "none" server-side, accepting unsigned tokens is a known critical vulnerability (CVE-2015-9235 class).