JWT Decoder

What Is a JWT?

A JSON Web Token is a compact way to pass signed information between systems, most often to prove who a user is after they log in. It looks like three blocks of text joined by dots: header.payload.signature.

• Header: The token type and the signing algorithm, such as HS256 or RS256
• Payload: The claims, meaning the data the token carries, such as a user ID, roles and an expiry time
• Signature: Proof that the header and payload were created by someone holding the key and haven't been changed

The header and payload are only Base64URL encoded, not encrypted. Anyone who has the token can read them, so never put passwords or other secrets in a JWT.

How to Decode a JWT

Step 1: Paste the Token

Copy the token from your browser's developer tools, an Authorization header or your app's logs and paste it into the Encoded token box. A leading Bearer is removed automatically. Click "Sample" to try a demo token.

Step 2: Read the Header and Payload

The token is decoded as you paste. Its three parts are coloured red, purple and cyan so you can see where each one starts, and the header and payload appear as formatted JSON.

Step 3: Check the Claims

The Claims panel lists the registered claims in plain language, and converts exp, iat and nbf from Unix timestamps into your local date and time, with a relative time such as "in 2 hours". The status line warns you if the token has expired or isn't valid yet.

Step 4: Verify the Signature

Enter the key and click Verify. For HS256, HS384 and HS512 this is the shared secret; tick "Secret is Base64 encoded" if your secret is stored that way. For RS, PS and ES algorithms, paste the public key in PEM format, starting with -----BEGIN PUBLIC KEY-----. You'll see whether the signature is valid, or a message explaining why it couldn't be checked.

Registered Claims Explained

• iss (Issuer): Who created the token, such as your auth server
• sub (Subject): Who the token is about, usually a user ID
• aud (Audience): Which service the token is meant for
• exp (Expires): When the token stops being valid
• nbf (Not before): When the token starts being valid
• iat (Issued at): When the token was created
• jti (Token ID): A unique ID, useful for revoking a single token

HS256 vs RS256 vs ES256

HS256 uses one shared secret to both sign and verify, so every service that verifies tokens can also create them. RS256 and PS256 use an RSA key pair: only the auth server has the private key, and anyone can verify with the public key. ES256 does the same with elliptic-curve keys, which gives much shorter signatures. For systems with several services, an asymmetric algorithm is usually the safer choice.

Security Tips

• Always verify the signature on your server. Decoding alone proves nothing
• Reject tokens with alg: "none", and pin the algorithm you expect instead of trusting the header
• Keep expiry times short, and check exp, nbf and aud on every request
• Only paste production tokens into tools that run locally, like this one

Privacy

Decoding and verification use your browser's built-in Web Crypto API. Tokens and keys are never uploaded or stored, and they are gone when you close the tab.

Conclusion

Whether you are debugging a login flow or checking why an API rejects a token, the JWT Decoder shows you the contents, the expiry and the signature status in one place. Try it at tools.typinks.com/jwt-decoder.