Paste a JSON Web Token to read its header and claims, see exactly when it expires, check it for risky settings, and optionally verify its signature. Everything happens in your browser.
A leading "Bearer ", an Authorization header line, quotes and line breaks are removed for you.
Runs entirely in your browser. Nothing you type or upload is sent to a server.
What is inside a JWT
A JSON Web Token is three pieces of text joined by dots: header.payload.signature. The header and payload are small JSON documents that have been turned into Base64URL, an alphabet of letters, digits, hyphens and underscores that survives being placed in a URL or HTTP header. The signature is binary data produced by a cryptographic algorithm, also Base64URL encoded. A decoder reverses the encoding of the first two parts and pretty-prints the JSON. No key is needed for that, because nothing is hidden.
The header describes the token. Its alg field names the signing algorithm, typ is usually JWT, and kid says which key was used so the server can choose the right one. The payload carries the claims, which are statements about the user or session.
The standard claims
| Claim | Meaning | What to check |
|---|---|---|
| iss | Issuer, the party that created the token | Must equal the issuer you trust |
| sub | Subject, usually the user ID | Stable identifier, not an email that can change |
| aud | Audience, the service the token is meant for | Your service must be listed, or a token for another API could be replayed against yours |
| exp | Expiration time, in seconds since 1970 | Reject at or after this moment |
| nbf | Not valid before | Reject until this moment |
| iat | Issued at | Useful for lifetime checks and forced re-login |
| jti | Unique token ID | Lets a server revoke or detect replay of one token |
Beyond these, issuers add their own claims, such as scope, email, roles and name. The decoder labels the ones it recognizes. All the time claims are counted in whole seconds, not milliseconds. A token whose exp is a 13-digit number was almost certainly built with JavaScript's Date.now() and will look valid for millennia to a strict library.
Decoding is not verifying
Reading a token tells you what it claims. Only checking its signature with the right key tells you the claim is true.
Because the payload is public and the format is simple, anyone can type a token that says "admin": true. What they cannot do is produce a valid signature for it without the secret or private key. Servers prove authenticity by recomputing the signature over the first two parts and comparing. The verification panel above does the same: HMAC algorithms (HS256, HS384, HS512) need the shared secret, while RSA (RS and PS), elliptic curve (ES) and EdDSA tokens need the issuer's public key as PEM, a certificate, or a JWK. If you do not have the key, the page can still read the token but should not be treated as proof of anything.
Red flags the decoder looks for
Algorithm none. An unsigned token. Any server that accepts one has no authentication at all. No expiry. A stolen token never ages out. A very long lifetime. More than 30 days between issue and expiry gives a thief a long window. jku, x5u or jwk in the header. These let the token point at, or carry, the key used to check it. A server that follows them without a strict allowlist will verify a forgery signed by the attacker's own key. Sensitive data in the payload. Passwords, card numbers and national ID numbers do not belong in something readable by anyone who holds it. A short HMAC secret. RFC 7518 requires an HS256 key of at least 32 bytes. A short or common secret can be recovered offline by trying guesses against a single captured token, which is why a secret like secret is as good as none.
Algorithm choice in practice
HMAC is the simplest: one secret signs and verifies, which suits one service talking to itself. The catch is that every verifier can also forge tokens. With RS256, ES256 or EdDSA the issuer keeps a private key and publishes a public one, so any number of services can verify tokens without being able to mint them. ES256 and EdDSA produce much shorter signatures than RSA at similar strength. Whichever you choose, the verifying code should fix the expected algorithm in configuration instead of reading it from the token, since the token is the thing being checked. Otherwise an attacker can switch an RS256 token to HS256 and sign it with the public key, which the server knows, or switch it to none.
When a token will not decode
The usual causes are copying the word Bearer along with the token (this tool strips it), a truncated copy from a log line, quotes or line breaks added by a terminal, and pasting a session ID that is not a JWT at all. Five parts means an encrypted token, which cannot be read without its key. For related developer utilities, see the Base64 converter, the JSON formatter and the cron expression explainer.
