How to decode a JWT online — safely
This JWT decoder splits a JSON Web Token into its header, payload and signature and shows each part as readable JSON. It highlights the signing algorithm, converts the exp and iat claims into real dates, and tells you whether the token has expired and how long it has left.
Tokens are credentials: anyone holding a valid access token can usually act as its owner. Many online decoders send what you paste to their servers. This one decodes locally in your browser and makes no network requests, so you can inspect production tokens without leaking them.
How to use the JWT decoder
- Copy a token from an
Authorization: Bearer …header, a cookie, or your identity provider's response. Paste just the token itself — leave out theBearerprefix. - Paste it into the token field. The header and payload are decoded instantly.
- Check the algorithm (
alg) in the header and the expiry panel, which shows when the token expires and whether it is still valid. - Hover over standard claims like
sub,iss,aud,exp,nbfandiatto see what each one means.
What's inside a JWT
A JWT is three Base64URL-encoded segments separated by dots: header.payload.signature. The header names the algorithm (HS256, RS256, ES256…) and token type. The payload carries claims — statements about the user and the token. The signature is computed over the first two segments with a secret or private key.
| Claim | Name | Meaning |
|---|---|---|
iss | Issuer | Who created and signed the token |
sub | Subject | Who the token is about, usually a user ID |
aud | Audience | Which service the token is intended for |
exp | Expiration | Unix time (seconds) after which the token must be rejected |
nbf | Not before | Unix time before which the token is not valid |
iat | Issued at | Unix time when the token was created |
jti | JWT ID | Unique token identifier, useful for revocation |
Because the payload is only encoded, not encrypted, anyone can read it. Never put passwords, API keys or personal data you wouldn't show the user into a JWT.
Decoding vs verifying
This tool decodes tokens; it does not verify signatures. Decoding tells you what a token claims. Verification — checking the signature with the right key, pinning the allowed algorithm, and validating exp, iss and aud — must happen in your backend with a maintained library. A decoded token that "looks right" may still be forged or expired.
For the full picture of how HMAC and RSA/ECDSA signatures work, and the classic alg: none and algorithm-confusion attacks, read How JWT signatures work.
Troubleshooting common JWT problems
- "Invalid JWT" — the input must have exactly three dot-separated parts. Check that you copied the whole token and didn't include quotes, a trailing newline, or the word
Bearer. - Token expired immediately — compare
iatandexp. Ifexpis 13 digits, the issuer used milliseconds instead of seconds. If times are a few minutes off, the issuing and verifying servers' clocks disagree; allow a small clock skew. - 401 with a token that looks valid — check the
audclaim matches your API, theissmatches the expected issuer, and thekidin the header matches a key in the issuer's JWKS. - Token has five parts — five dot-separated segments means it's a JWE (an encrypted token). Its payload cannot be read without the decryption key, so the decoder reports it as invalid.
To convert a timestamp claim by hand, paste it into the Unix timestamp converter. To decode an individual Base64URL segment, use the Base64 decoder.
Frequently asked questions
Is it safe to paste a JWT into this decoder?
Yes. Decoding happens entirely in your browser with JavaScript; the token is never sent to a server or stored remotely. Your tool history is kept only in your browser's local storage, and you can clear it at any time.
Can this tool verify a JWT signature?
No. It decodes and inspects tokens. Signature verification requires the issuer's secret or public key and should be done server-side with a JWT library.
Why can I read the payload without a key?
JWT payloads are Base64URL-encoded, not encrypted. The signature only prevents tampering; it doesn't hide the contents. Use JWE if the claims must be confidential.
What does the exp claim mean?
exp is the expiration time as a Unix timestamp in seconds. After that moment, a correctly configured server must reject the token. The decoder converts it to your local date and time and shows the remaining lifetime.
Further reading
- How JWT Signatures Work (HS256 vs RS256, Explained)What the three parts of a JSON Web Token are, how the signature is computed, why decoding is not verifying, and the mistakes that lead to JWT vulnerabilities.
- Unix Timestamps Explained: Seconds vs Milliseconds, Timezones and 2038What a Unix (epoch) timestamp is, how to tell seconds from milliseconds, converting in JavaScript, Python and SQL, and the timezone and Year 2038 pitfalls.