How to use the jwt decoder
- Paste a JSON Web Token into the box. A leading Bearer and any line breaks are removed for you. Use Use a sample token if you only want to see how it works.
- Read the header, which names the signing algorithm and token type, and the payload, which holds the claims.
- Check the standard claims table. Times such as expires, issued at and not valid before are converted from seconds to UTC dates and compared with your device clock.
- Use Copy payload or Copy header to take the formatted JSON. Remember that decoding does not check the signature.
Decoding the classic sample token
The sample token has the header {"alg":"HS256","typ":"JWT"} and the payload {"sub":"1234567890","name":"John Doe","iat":1516239022}. The issued at value 1516239022 is 2018-01-18T01:30:22Z. The signature part is 43 characters long and is shown only by length, because it is not verified.
In a second example, a token with iat 1700000000 and exp 1700003600 has an hour between those two moments. Checked 30 minutes after it was issued, the tool reports that it expires 30 minutes after the check time, and that it became valid 30 minutes before the check time.
What a JWT contains
A signed token has three parts separated by dots: a header, a payload and a signature. The first two are JSON documents written in base64url, a variant of Base64 that uses a hyphen and an underscore and drops the padding. Anyone who holds the token can read them. They are encoded, not encrypted.
Common payload claims have short names: iss is the issuer, sub the subject, aud the audience, exp the expiry time, nbf the not-before time, iat the issued-at time and jti a token identifier. Times are counted in seconds since 1970-01-01 UTC. A token with five parts is an encrypted token, and only its header can be read without the key.
Decoding is not verifying
This tool never checks the signature, and it cannot tell you whether a token is genuine, current on the server, or allowed to do anything. A token with the algorithm "none" is unsigned, and the tool points that out. Servers must verify the signature and the claims themselves before trusting a token.
The token is processed in your browser and is not sent or stored. Even so, treat live tokens like passwords. Prefer a token from a test environment, and remember that a token you paste into any page can be used by whoever sees it. For related work, see the Base64 encoder and decoder, the Unix timestamp converter and the JSON formatter.
Assumptions and limits
- Times are read as seconds since 1970-01-01 UTC and compared with your device clock, so a wrong clock changes the expired and not-yet-valid messages.
- Only registered claim names are given friendly labels. Other claims are shown in the payload as written.
- Tokens over 50,000 characters are refused so the page stays responsive.
- Header and payload must be valid UTF-8 text. A payload that is not JSON is shown as plain text.
Frequently asked questions
Can this tool tell me if a JWT is valid?
No. Valid means the signature checks out with the right key and the claims are acceptable, and that has to be checked on a server that holds the key. This page only decodes what is written in the token.
Is a JWT encrypted?
A normal signed JWT is not encrypted. Its header and payload are base64url text that anyone can decode, so do not put secrets in the payload. Only a five-part encrypted token hides its contents.
What do exp, iat and nbf mean?
exp is when the token stops being valid, iat is when it was issued and nbf is the earliest time it may be used. All three are counted in seconds since January 1, 1970 UTC.
Is it safe to paste a real token here?
The decoding happens in your browser and the token is not sent anywhere. Still, a live token can act like a password, so use test tokens when you can and avoid sharing screenshots of real ones.