JWT decoder & inspector
Paste a JSON Web Token to read its header and claims and see whether it has expired. Decoding happens in your browser; the token is never sent anywhere and no signing key is needed. A decoded token is not a verified one: this tool does not check the signature.
Paste a token above to decode its header and payload.
Decoding runs entirely in your browser — nothing is sent anywhere. Even so, avoid pasting production tokens into any online tool: a JWT payload is only base64-encoded, not encrypted, so treat it like a password.
The three parts of a JWT
Header
The token type and the signing algorithm (for example alg: HS256).
Payload
The claims — subject, issuer, audience, issued-at and expiry times, plus any custom data.
Signature
Proves the token was issued by a party holding the signing key. Verifying it needs that key.
JWT questions, answered
What is a JWT?
A JSON Web Token is a compact, URL-safe way to represent claims between two parties. It has three parts separated by dots — a header, a payload, and a signature — each base64url-encoded. It is commonly used for authentication and session state.
Does this verify the signature?
No. Verifying a signature requires the signing secret or public key, which this tool does not have and never asks for. It decodes the header and payload so you can read the claims, but it cannot and does not confirm the token is authentic or untampered.
Is a JWT encrypted?
Usually not. A signed JWT, the common kind, is only base64url-encoded; anyone who has the token can read its payload. (The JWT specification also allows an encrypted form, which this tool cannot read.) That is why you must never put secrets in a JWT payload, and why you should treat a token itself like a password.
Is my token sent to a server?
No. Decoding happens entirely in your browser with JavaScript. Nothing you paste is transmitted, logged, or stored. As a rule, still avoid pasting live production tokens into any web tool.
How do I know if a token is expired?
The exp claim holds an expiry time as seconds since 1970 (Unix epoch). This tool reads it, converts it to a readable date, and tells you whether that moment is in the past. Note this reflects the claim inside the token, not whether the issuing server still considers the session valid.
How to read a decoded token
- Header. Says how the token was signed. alg is the signing algorithm and typ is usually JWT.
- Payload. The claims. Common ones are iss (who issued it), sub (who it is about), aud (who it is for), iat (issued at) and exp (expiry).
- Signature. Proves the first two parts were not changed. It can only be checked with the key, which is why this tool shows it but cannot confirm it.
The expiry rule comes from the JWT standard:
“The “exp” (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.”
Security checks worth making on any token
Decoding is the easy part. These are the mistakes testers look for when they review how an application uses tokens.
“The algorithm can be changed to “none” by an attacker, and some libraries would trust this value and “validate” the JWT without checking any signature.”
- If the header says alg: none, the token carries no signature. It should be rejected by an API that expects signed tokens.
- Sensitive data in the payload is readable by anyone holding the token. A JWT is encoded, not encrypted.
- A very long or missing exp means a stolen token stays useful for as long.
Related tools and guides
Worried about how your app handles tokens?
Weak JWT handling — the none algorithm, unverified signatures, secrets in the payload — is something a web-app penetration test can check. Compare UK penetration testing companies in our directory.
Browse the directory