JWT Decoder
Paste a JWT to see its header, payload and signature, find out whether it is still valid and check its roles and scopes. It decodes as you paste.
The token, the secret and the public key stay in your browser. None of it is sent to any server, ours included, and it is gone when you close the page.
No token yet
Paste a JWT into the field. Its status, dates and claims show up here right away.
Need a token with other claims, like an admin and a regular user?
How to use the JWT Decoder?
Paste the token
Copy it from DevTools, Postman or a log and paste it. Bearer, quotes and line breaks are removed for you.
Check the status
The status tells whether the token expired, when it expires and at what time, in your time zone and in UTC.
Check the signature
Enter the secret or the public key to find out whether the token is authentic and unchanged.
Copy what you need
Copy the clean token, the header, the payload or a single claim value with one click.
What is a JWT?
A JWT (JSON Web Token, RFC 7519) is a token format for passing information between systems, mostly for login and API authorization. The authentication server issues the token after login, the application sends it with every request, and the API reads its claims to know who the user is and what they may do.
The three parts of a JWT
A JWT has three base64url sections separated by dots:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsInJvbGVzIjpbInVzZXIiXX0.3mG4X8mY2bJqS0mY7fUv0M1wS6Qy0p2WmH0x0J3bQKc- Header. The header says which algorithm signed the token (alg) and sometimes which key was used (kid).
- Payload. The payload holds the claims: who the user is, when the token expires, which API it is for and what permissions it grants.
- Signature. The signature is computed over the header and the payload. If a single character changes, it no longer matches.
Why you can read the payload without a password
The header and payload are only encoded in base64url, a Base64 variant that swaps + and / for - and _ and drops the trailing =. Encoding is not encryption: anyone holding the token can read its content, which is exactly what this tool does. That's why passwords, card numbers and other sensitive data never belong in a JWT payload.
Registered and custom claims
RFC 7519 defines seven registered claims: iss, sub, aud, exp, nbf, iat and jti. They have short names and fixed meanings, and JWT libraries check exp, nbf and aud automatically. Everything else is a custom claim, created by the application or the identity provider, such as roles, scope, email or realm_access in Keycloak. In the claims table, each known claim comes with a short explanation.
Decoding is not validating
Reading the payload proves nothing about the token. Anyone can build a JWT with an admin sub and an exp ten years from now. Authenticity comes from the signature, and the backend is the one that must check it, always with the algorithm pinned in its configuration instead of whatever the header says. Use the check on this page for debugging, never as a replacement for server-side validation.
The risk of alg none
An alg of "none" means an unsigned token. Some old libraries accepted such tokens when the header asked for it, so an attacker only had to change alg and drop the signature to pose as any user. When this tool finds alg none, it shows a warning. If your API accepts a token like that, treat it as a security bug.
JWS and JWE: signed or encrypted
Almost every JWT you run into is a JWS: signed, with three parts and a readable payload. A JWE is the encrypted version, with five parts, and only whoever holds the decryption key can read it. If you paste a JWE here, the tool tells you so and shows only the header, which stays readable.
Where to find the token to paste here
- In a request's Authorization: Bearer header, in the DevTools Network tab or in Postman and Insomnia
- In a session cookie, in the DevTools Application tab (the cookie may be HttpOnly and invisible to JavaScript)
- In the response from the provider's token endpoint, in the access_token and id_token fields
- In API gateway and application logs, often split across several lines
Common problems when debugging login and permissions
Login fails with 401 after a while
The status shows whether exp has passed and how long ago. If the token expires within minutes, check that the front end uses the refresh token to get a new one.
A logged-in user gets 403
Look at the roles and scopes block. If the expected role isn't there, the problem is in the provider's configuration or in the kind of token being sent (sending the ID token instead of the access token is a common mistake).
Token rejected right after it was issued
exp, iat and nbf count seconds in UTC and don't depend on time zones. When a brand new token is rejected, the cause is usually clock skew between servers. Dates are shown in your time and in UTC to make comparing with logs easier.
Valid token rejected by another API
Check aud. Each API should only accept tokens issued for it, so one API's token won't work for another.
Frequently Asked Questions about the JWT Decoder
What usually comes up when reading and debugging JWTs.