JWT decoder

Runs in your browser; nothing is uploaded

Read a JSON Web Token's header and claims, see when it expires, and check its signature with your secret or public key.

Token

Verify signature

Paste a token to check its signature against a secret or public key.

No token yet

The header and payload appear here as JSON, and Claims lists each claim with what it means and when it expires.

Ready

What is a JWT?

A JSON Web Token (JWT) is a compact, signed way of passing claims between two parties, most often from an authentication server to an API. It is three Base64url strings joined by dots, header.payload.signature, and APIs usually expect it in the Authorization: Bearer <token> header.

The header says how the token is signed, for example "alg": "HS256" for an HMAC with a shared secret or RS256 for an RSA key pair. The payload holds the claims: standard ones such as sub (who the token is about), iat (when it was issued) and exp (when it expires), plus whatever the issuer adds, such as roles or scopes.

The signature is what makes a token trustworthy. The issuer computes it over the header and payload with its key, so changing one character of the payload breaks it. The payload is encoded, not encrypted: anyone who has the token can read every claim, so never put secrets in one, and treat the token itself like a password until it expires.

How to use this tool

1Paste a token into the Token pane, or pick one from Examples. A Bearer prefix, an Authorization: header name, quotes and line breaks are ignored, and the pane header says what was ignored.
2The header, payload and signature are colored in the token. Payload and Header show each part as JSON; Claims lists every claim with what it means, and shows iat, nbf and exp as dates in your time zone with how long ago or ahead they are.
3The status bar shows the algorithm, when the token expires or expired, and whether the signature was checked. Warnings such as alg: none or a missing exp are listed at the top of Claims.
4To check the signature, enter the shared secret (HS256, HS384, HS512; switch to Base64 if the secret is encoded) or paste the issuer's public key (RS*, PS*, ES*, EdDSA) as PEM, an X.509 certificate, a JWK or a JWK set. The result appears as you type.
5If the token can't be decoded, the message says which part and which character is wrong; press F8 to select it.

Troubleshooting

This token has 5 parts: it is an encrypted JWE: Some identity providers issue encrypted tokens (JWE). Their payload can only be read with the recipient's private key, so no decoder can show it without that key.
+ is standard Base64; JWTs use Base64url: The token was re-encoded or built by hand with standard Base64. JWT parts use - and _ instead of + and /, with no = padding.
The signature doesn't match this secret: Check that the secret is exactly the one the issuer uses, including case and trailing spaces, and whether it is stored as Base64; if so, switch the secret format to Base64.
This is a PKCS#1 RSA key (BEGIN RSA PUBLIC KEY): Browsers only import keys in SubjectPublicKeyInfo form. Convert it with openssl rsa -RSAPublicKey_in -in key.pem -pubout, or paste the JWK from the issuer's JWKS endpoint instead.
The key set has no key with this kid: Issuers rotate keys. Fetch the current JWK set from the issuer's jwks_uri and paste it again; the tool picks the key whose kid matches the token's header.

Frequently asked questions

Is it safe to paste a real token or secret here?

Decoding and signature checks run in your browser with Web Crypto, and nothing is sent anywhere. The token is kept in this tab's session storage until you clear it or close the tab, so a reload doesn't lose it; the secret or key you verify with is never stored, and tokens are never put in links. Even so, a live token grants access until it expires, so prefer test or expired tokens, and never paste production signing secrets into any website you don't control.

What does "Signature verified" mean?

That the header and payload were signed with the secret or the private key that belongs to the public key you gave. It doesn't say the token is acceptable: your API must also check exp, nbf, the issuer (iss) and the audience (aud), and must decide which algorithms it accepts.

Why is alg none dangerous?

A token with "alg": "none" has no signature, so anyone can write one with any claims. Libraries that accept it by mistake let attackers forge tokens. Servers should reject unsigned tokens.

What format are iat, nbf and exp in?

Seconds since 1 January 1970 UTC (Unix time). A 13-digit value is milliseconds, which is a common bug in token issuers; the tool warns about it. The Unix timestamp converter turns any of these into a date.

Why is my token rejected when it decodes fine?

Common causes are a signature from a different key, a wrong aud or iss, a token used before its nbf time or after exp, or clocks that differ between servers. Read the API's error response and compare those claims.