How to use it
- Copy a token from an Authorization header, a cookie or your browser's developer tools. A leading “Bearer ” is removed automatically.
- Paste it into the box. The header and payload appear as formatted JSON.
- Check the status line and the claims table for the issuer, audience and expiry dates in your local time.
- Copy the header or payload JSON if you need it elsewhere.
How it works
A JSON Web Token (JWT, RFC 7519) in its common signed form (JWS) consists of three base64url-encoded parts separated by dots. The header says which algorithm signed the token, for example HS256 (HMAC with SHA-256) or RS256 (RSA). The payload contains the claims: statements about the user and the token itself. The signature lets the server check that header and payload have not been changed.
The header and payload are only encoded, not encrypted. Anyone who has a token can read its contents, which is exactly what this tool does. Do not put secrets in JWT payloads.
Decoding does not prove anything about a token. Without the issuer's key, nobody can tell whether the signature is genuine, so the result here must never be used to decide whether to trust a token. Verification belongs on your server, with a maintained JWT library that checks the signature, the algorithm, exp, nbf, iss and aud.
The registered claims are explained in the table. exp, nbf and iat are NumericDate values: seconds since 1 January 1970 UTC. The tool converts them to dates in your time zone and compares them with your device's clock, without the small leeway servers often allow for clock differences. If your clock is wrong, the status will be wrong too.
Tokens with five parts are encrypted JWTs (JWE). Their payload cannot be decoded without the key, so the tool only reports the format.
Examples
Why is my API returning 401?
Decode the access token your app sends. If the status line says “Expired on …”, the client needs to refresh the token. If aud shows https://api.example.com but you are calling https://api2.example.com, the audience does not match.
Checking an OpenID Connect ID token
An ID token from a login provider contains iss (the provider), sub (the stable user ID), aud (your client ID), iat and exp, plus profile claims such as email and name. Decoding it shows which claims your app actually receives.
Reading a timestamp claim
A payload contains "exp": 1735689600. The claims table shows it as 1 January 2025, 00:00:00 UTC, converted to your local time, together with how long ago or how far in the future that is.
Frequently asked questions
Does this tool verify the JWT signature?
No. It only decodes the header and payload. Verifying requires the secret (for HS256) or the issuer's public key (for RS256 and ES256) and should be done on your server with a trusted library.
Is it safe to paste my token here?
The token is decoded in your browser and is not sent anywhere. Even so, a valid token works like a password until it expires, so prefer expired or test tokens, and never paste production tokens into tools you do not trust.
Why can anyone read the payload?
Signed JWTs are encoded with base64url, which is not encryption. The signature protects the token against changes, not against reading. If the contents must be secret, use an encrypted JWT (JWE) or keep the data on the server.
What does “exp” mean, and in which unit is it?
exp is the expiration time as a NumericDate: whole seconds (not milliseconds) since 1970-01-01 00:00:00 UTC. A token must be rejected at or after that moment.
Why do I get “not valid base64url”?
The token was probably cut off or changed while copying, for example by losing its last characters, quotes around it, or URL encoding (%2E instead of a dot). Paste the raw token exactly as it was issued.
Privacy
The token is decoded with JavaScript in your browser. It is not sent to any server, not stored, and not included in analytics. No signature verification or key lookup takes place, so no network request is made.