JWT Decoder

Decode and validate JSON Web Tokens (JWT). View header, payload, and signature instantly. Everything runs in your browser — nothing is sent to any server.

0 characters

What is a JWT?

Authentication API Tokens Session Management Authorization
token reports invalid signature—what should I check?
Three steps: 1) confirm the algorithm matches (if the server uses RS256, don't use HS256), 2) verify the secret/public key is correct (don't mix up test and production keys), 3) check the payload hasn't been tampered with (changing exp or uid invalidates the signature). This tool decodes and displays content only—it cannot verify signatures.
How do I refresh an expired token?
Check the payload for a refresh_token field: if present, call your backend to exchange it for a new access token. If absent, the user must re-authenticate. Proactively refresh before expiry to avoid failed requests.
What does the exp timestamp mean? Has it expired?
exp is a Unix timestamp in seconds. This tool converts it to a human-readable date and shows "Expired X hours ago" or "Expires in X hours." If a token has no exp, it never expires—handle with care.
What are the three parts of a JWT and what can I see?
header.payload.signature. Header and Payload are Base64URL-encoded JSON—anyone can decode them to see content (username, permissions, expiry, etc.). The Signature prevents tampering and requires the secret key to verify. This tool decodes the first two parts.
HS256 vs RS256—which one should I use?
HS256 (symmetric): same secret key on both sides—simple but risky if the key leaks. RS256 (asymmetric): signed with private key, verified with public key—better for microservices. What you use depends on your backend; this tool decodes both.
Try SHA-256 Hash →

Decoding a JWT Does Not Verify It

A JSON Web Token has three parts: header, payload, and signature. The first two parts are Base64URL-encoded JSON, which means they are readable by anyone who has the token. Decoding a JWT helps you inspect claims such as sub, iss, aud, iat, and exp, but it does not prove that the token is trusted.

Verification requires the correct secret or public key and must be performed by the application or backend that owns the authentication system. This distinction matters: a token can look valid after decoding while still having a bad signature, the wrong audience, an expired timestamp, or claims that should not be accepted by your service.

Safe JWT Debugging Checklist

Check the algorithm.
Make sure the expected algorithm matches the token header. Mixing HS256 and RS256 is a common source of verification failures.
Check expiration and clock skew.
The exp, nbf, and iat claims use Unix timestamps in seconds. A server clock that is several minutes off can make a good token appear invalid.
Do not treat JWT payloads as private.
JWT payloads are usually signed, not encrypted. Avoid putting passwords, API keys, personal identifiers, or internal secrets in the payload.
Validate issuer and audience.
A token from another environment or another service may decode correctly. Your backend should still reject it if iss or aud is wrong.
Ctrl + Enter to decode  ·  Ctrl + Shift + C to copy