How to decode a JWT
- Paste the token into the box. You can paste it with or without the
Bearerprefix from anAuthorizationheader; line breaks copied from logs are removed. - Read the header. It tells you the signing algorithm (
alg), usually the type (typ), and sometimes a key ID (kid) that points to the key used to sign it. - Read the payload. These are the claims: who issued the token (
iss), who it is about (sub), who it is meant for (aud) and when it is valid. - Check the dates.
exp,nbfandiatare NumericDate values, the number of seconds since 1970-01-01T00:00:00Z. The tool converts them to readable dates and shows whether the token has expired. - Remember what is not checked. The signature is shown but not verified, because verification needs the secret or public key.
What a JWT is made of
A JSON Web Token, defined in RFC 7519, is three base64url-encoded parts joined by dots: header.payload.signature. Base64url is the URL-safe Base64 alphabet from RFC 4648, which uses - and _ instead of + and / and usually drops the = padding. That is why a token can travel in a URL or HTTP header without further escaping, and also why anyone holding it can read the contents. The header and payload are encoded, not encrypted.
For a longer explanation of why decoding is easy and why it is not the same as trusting a token, read how to decode a JWT without the secret.
Examples
| Token (shortened) | Header | Payload | Notes |
|---|---|---|---|
eyJhbGciOiJIUzI1NiIs…aWbbNTz… |
{"alg":"HS256","typ":"JWT"} |
{"sub":"1234567890","name":"Jane Doe","iat":1767225600,"exp":1767229200} |
Issued 2026-01-01 00:00 UTC, expired one hour later |
| RFC 7519 section 3.1 example | {"typ":"JWT","alg":"HS256"} |
{"iss":"joe","exp":1300819380,"http://example.com/is_root":true} |
exp is 2011-03-22 18:43 UTC |
eyJhbGciOiJub25lIn0.eyJzdWIiOiJ4In0. |
{"alg":"none"} |
{"sub":"x"} |
Unsecured JWT: empty signature, flagged with a warning |
…eyJuYW1lIjoiWm_DqyJ9. |
— | {"name":"Zoë"} |
Non-ASCII text decoded as UTF-8 |
Common claims at a glance
| Claim | Meaning (RFC 7519) | Shown as |
|---|---|---|
iss |
Issuer | Text |
sub |
Subject, usually a user ID | Text |
aud |
Audience: string or array | Text or list |
exp |
Expiration time | Date + "expired" or "expires in" |
nbf |
Not before | Date + "not yet valid" if in the future |
iat |
Issued at | Date |
jti |
Unique token ID | Text |
When this tool helps
- Debugging login problems. Check whether
exphas passed orauddoes not match the API you are calling. - Comparing environments. See which issuer or key ID a staging token uses compared with production.
- Reviewing what you expose. Anything in the payload can be read by the client, so it should not contain secrets.
Limits
- No signature verification. A decoded token can be forged or modified; only signature verification with the right key proves it came from the issuer.
- No decryption. Encrypted tokens (JWE, five parts) keep their payload secret; only the protected header is readable.
- Clock differences. Expiry status uses your device clock. Servers often allow a small leeway for clock skew, as RFC 7519 permits.
If you need to look at other encoded strings from the same request, the universal encoder decoder handles Base64, URL encoding and hex, and the URL parser splits callback URLs into their parameters.
Frequently asked questions
Does this JWT decoder verify the signature?
No. It only decodes the header and payload, which are base64url-encoded JSON. Verifying a signature needs the secret or public key and must be done by the application that trusts the token.
Is it safe to paste a production token here?
The decoding runs in JavaScript in your browser and the token is not sent to the server. Even so, treat live access tokens as passwords: prefer expired or test tokens when you only need to inspect the structure.
Why does my token have five parts instead of three?
A five-part token is an encrypted JWE. Its payload is ciphertext, so it cannot be read without the decryption key. This tool decodes the protected header only and tells you the payload is encrypted.