How to decode a JWT
- Paste your token into the JWT box. A sample token is already loaded. A whole
Authorization: Bearer ...header is fine, because the prefix is removed for you. - Read the Header panel (the signing algorithm is
alg), the Payload panel and the Claims table. The banner above them says whether the token has expired or is not valid yet. - To check the signature, type the secret in Secret (HS256, HS384, HS512) or paste a public key in Public key (RS, PS, ES and EdDSA tokens). The result reads "Signature verified" or "Invalid signature".
How it works
A JWT is three Base64URL strings joined by dots, as defined in RFC 7519 and RFC 7515. The tool decodes the first two parts to UTF-8 text and parses them as JSON, so accented names and emoji display correctly and numbers appear exactly as written. The times exp, nbf and iat count seconds since 1 January 1970 UTC and are compared with your device clock.
Verification recomputes the signature over the first two parts exactly as they appear in the token, using the algorithm in the header: HMAC for HS, RSASSA-PKCS1-v1_5 for RS, RSASSA-PSS for PS, ECDSA for ES (RFC 7518) and Ed25519 for EdDSA. It then compares the result with the token's signature.
Worked example
The default token has the header {"alg":"HS256","typ":"JWT"} and a payload for sub 1234567890, issued by https://auth.example.com to https://api.example.com, plus name, email and role claims. The claims table shows iat and nbf as 2026-01-01 00:00:00 UTC (1767225600) and exp as 2100-01-01 00:00:00 UTC (4102444800), so the banner says the token is not expired and counts the time left. The Signature panel shows 32 bytes of hex, starting 531f8d02 and ending 51ce3ace.
With your-256-bit-secret in the Secret box, the check reads "Signature verified." Change one character of the secret and it reads "Invalid signature."
Limits and edge cases
- Decoding is not trusting. Anyone can write a token with any claims, so only a verified signature, plus your own checks of
iss,audandexp, means anything. - Encrypted tokens (JWE) have five parts and cannot be read without the decryption key, so the tool says so. An unsigned token (
algofnone) is flagged and never reported as verified. - The expiry check uses your device clock with no leeway, so a clock a few minutes off can make a good token look expired.
- Public keys can be PEM, an X.509 certificate, a JWK or a JWKS (matched by
kid). Private keys are refused. EdDSA needs a browser that supports Ed25519.
Frequently asked questions
Is it safe to paste a JWT into an online decoder?
Here the token is decoded in your browser and is not sent to a server. A live access token still works like a password until it expires, so prefer a test token, or one you can revoke, when debugging.
Can I decode a JWT without the secret?
Yes. The header and payload are only Base64URL encoded, not encrypted, so anyone holding the token can read them. The secret or public key is needed only to check the signature.
What is the difference between decoding and verifying a JWT?
Decoding turns the first two parts back into readable JSON. Verifying proves the token was signed with a particular key and was not altered. A decoded token can be forged, but a verified one cannot, unless the key has leaked.
Why does the decoder say my token is expired?
The exp claim is in the past compared with your device clock. Check that the clock is right and that exp is in seconds, not milliseconds. If the token really has expired, request a new one.
Why can't I decode a token with five parts?
A five-part token is an encrypted JWE, and its payload is unreadable without the decryption key. Only three-part signed tokens (JWS) can be decoded here.
Next steps: decode the pieces by hand with the Base64 encoder and decoder, tidy a payload in the JSON formatter, turn an exp value into a date with the timestamp converter, or compare checksums with the hash generator. For background, read JWT tokens explained.