How to use the JWT decoder
- Paste a token into the box. A leading
Bearer, quotes and line breaks are removed for you. - Read the header and payload as formatted JSON. Use Copy to take either one.
- Check the times on the right:
exp,nbfandiatare shown as dates in UTC and your own time zone, with a status of Expired, Not valid yet, Not expired or No expiry.
No token to hand? Example token fills in a made-up one. Its issuer is auth.example.com and its signature is just the words "not-a-real-signature" in base64url, so it is not signed by anyone.
Decoding is not verifying
The header and payload of a signed JWT are only encoded, not encrypted. Anyone who has the token can read them, with this page or with a few lines of code. So never put secrets in a JWT payload: no passwords, no keys, nothing you would not show the person holding the token.
What protects a JWT is its signature, and this decoder does not check it. A decoded token that looks right can still be forged or altered. The time status on the right reads the claims only. Always verify signatures on your server, with your JWT library, the expected algorithm and the right key.
About pasting tokens: this page decodes in your browser and sends nothing anywhere. Even so, it is a good habit not to paste live production tokens into any website. A token that has not expired works for whoever holds it, so test with a short-lived or development token, or the example.
How a JWT is put together
RFC 7519 says "A JWT is represented as a sequence of URL-safe parts separated by period ('.') characters". A signed JWT (a JWS) has three parts: header.payload.signature. An encrypted JWT (a JWE) has five, and its payload can only be read with the key, so this page shows its header only.
Each part is encoded with base64url. RFC 4648 section 5 defines it as base64 with a URL and filename safe alphabet, where value 62 is - (minus) and 63 is _ (underline), instead of + and /. JWTs also drop the padding: RFC 7515 uses base64url "with all trailing '=' characters omitted". The decoder accepts +, / and = too, but warns you, because strict libraries reject them.
Worked example: the sample token in RFC 7519 section 3.1 starts with eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9. Decoded, that header is {"typ":"JWT", "alg":"HS256"}. Its payload decodes to:
| Claim | Value | Meaning |
|---|---|---|
iss | "joe" | Issued by "joe" |
exp | 1300819380 | Expires 22 March 2011, 18:43:00 UTC |
http://example.com/is_root | true | A private claim |
Its signature part decodes to 32 bytes, the length of an HMAC SHA-256 value, which matches "alg": "HS256".
Registered claims
RFC 7519 section 4.1 defines seven claim names. None is required, but when present they mean:
| Claim | Name | RFC 7519 says it |
|---|---|---|
iss | Issuer | "identifies the principal that issued the JWT" |
sub | Subject | "identifies the principal that is the subject of the JWT" |
aud | Audience | "identifies the recipients that the JWT is intended for" |
exp | Expiration time | is the time "on or after which the JWT MUST NOT be accepted for processing" |
nbf | Not before | is the time "before which the JWT MUST NOT be accepted for processing" |
iat | Issued at | "identifies the time at which the JWT was issued" |
jti | JWT ID | "provides a unique identifier for the JWT" |
The times are NumericDate values: "the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds". That is a Unix timestamp in seconds, so a 13-digit value is probably milliseconds by mistake, and the decoder flags it. aud can be a single string or an array of strings.
The status uses your device's clock with no leeway. A token is Expired from the exact second of exp. Servers often allow a little clock skew, as RFC 7519 permits: "usually no more than a few minutes".
When a token will not decode
- Wrong number of parts: a JWT has two dots (three parts), or four dots if it is encrypted. A token cut short when copying often has one dot or none.
- Not valid base64url: the part contains a character outside A to Z, a to z, 0 to 9,
-and_, or its length is impossible. Look for a missing or extra character at the end. - Not valid JSON: the part decodes, but not to a JSON object. It may be a different kind of token, such as an opaque access token that is not a JWT at all.
Text in other languages and emoji are decoded as UTF-8, so a name like Zoë or 東京 shows correctly.
Questions and answers
Does this JWT decoder verify the signature?
No. It only decodes the header and payload. A decoded token can still be forged, so check the signature on your server with your JWT library and the right key.
Is it safe to paste my token here?
The token is decoded by code in this page and is never sent anywhere or stored. Still, avoid pasting live production tokens into any website. Use a development or expired token, or the example.
Can anyone read the contents of a JWT?
Yes, for a signed JWT. The header and payload are base64url-encoded, not encrypted, so anyone holding the token can read them. Do not put secrets in the payload.
What does exp mean, and is my token expired?
exp is the expiration time, in seconds since 1 January 1970 UTC. The token must not be accepted on or after that moment. The decoder shows it as a date and says Expired or Not expired from your device clock.
Why does my token show as not valid yet?
Its nbf (not before) time is still in the future by your device clock. If it is only a few seconds or minutes out, the issuing server's clock and yours may differ slightly.
Can it decode an encrypted JWT?
It shows the header of an encrypted JWT (five parts). The payload needs the decryption key, which this page does not ask for.
Sources
Checked on 7 October 2026. If a rule has changed, please tell us.