JWT DecoderDeveloper Tools
Decodes JSON Web Tokens, explains the claims, and verifies HS, RS, PS, and ES signatures.
A request fails with 401 and the only clue is a long string that starts with eyJ. Decode it to read the claims, then verify the signature before you believe any of them.
A signed JWT has three parts joined by dots: header.payload.signature. The header and payload are JSON written in Base64URL, which is Base64 with - and _ in place of + and /, and no padding. Anyone can decode them without a key, because a JWT is signed, not encrypted.
If you only decode a token, you may be reading a user ID and an expiry time that someone typed in themselves. A server that accepts alg none, or trusts a key the token supplies in its own header, lets anyone write their own claims. And since the payload is readable, a password or secret placed there is exposed to every client that holds the token.
Paste the token into the JWT Decoder. It shows the decoded header and payload and a claims table that turns exp, iat, and nbf from Unix seconds into dates and says whether the token has expired. To check the signature, paste the shared secret for HS algorithms, or a PEM public key for RS, PS, and ES, and press Verify. The check runs in your browser with the Web Crypto API, and the token is not sent to a server.
When the key comes from an identity provider, use the JWT Inspector. It takes a secret, a PEM key, a single JWK, or the whole JWKS, and picks the key whose kid matches the token. It applies the clock skew your service allows and puts iat, nbf, exp, and the current time on one timeline. It also warns about alg none, a short HMAC secret, a missing exp, a jku, x5u, or jwk in the header, and an exp that looks like milliseconds. It doesn't fetch the JWKS for you, so copy it from your provider's jwks_uri.
If a part refuses to decode, look at it in the Base64 Encoder and Decoder. It accepts both the standard and the URL-safe alphabet and missing padding, so you can decode the payload on its own and see whether it is valid JSON. Characters outside the alphabet, or an impossible length, give an error. That points to a token that was cut short or pasted with extra text around it.
Yes. The header and payload are only Base64URL encoded, not encrypted. Never put passwords or other secrets in a JWT payload.
These tools decode and verify in your browser and don't send the token anywhere. Still, treat live production tokens like passwords, prefer test tokens, and never paste a private key into any website.
The secret may be stored as Base64, and some systems sign with its decoded bytes. Tick Secret is Base64 encoded and try again.
The exp claim is earlier than your device's clock. Get a new token from the issuer, or set the clock skew your service allows in the JWT Inspector.
Tools used in this guide
Decodes JSON Web Tokens, explains the claims, and verifies HS, RS, PS, and ES signatures.
Signature check with JWKS key selection, a claim timeline with clock skew, and security warnings.
Encodes and decodes Base64 for text and files.