Decode and verify JWTs locally

JWT Inspector

Paste a JWT, paste an HMAC secret, and see the decoded header and payload. Verifies the signature with WebCrypto and flags exp, nbf, and the unsafe none algorithm.

Reading and checking a JSON Web Token

A JSON Web Token (JWT) is a compact, signed piece of JSON that services pass around to say who you are and what you may do. Login systems issue them after sign-in, and APIs read them on every request. A JWT has three parts separated by dots: a header that names the signing algorithm, a payload of claims such as the user ID and expiry time, and a signature.

The header and payload are only Base64URL-encoded, not encrypted, so anyone holding the token can read them. The signature is what makes the token trustworthy: without the right key, nobody can change a claim without breaking it. This inspector decodes all three parts and, for HMAC tokens, checks the signature with your secret, all inside your browser.

How to use it

  1. Paste the token into the JWT box. The decoded header and payload appear at once.
  2. Check the time claims: exp (expires), nbf (not valid before) and iat (issued at) are shown as readable dates.
  3. For tokens signed with HS256, HS384 or HS512, paste the shared secret to verify the signature with WebCrypto.
  4. Read the verdict. The tool also warns when a token uses the alg none, which means it has no signature at all.

Example: the classic jwt.io sample token

Input
Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Secret: your-256-bit-secret
Output
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}
iat: 2018-01-18T01:30:22.000Z
Signature is valid.

Change one character of the secret and the verdict turns to a mismatch. Change one character of the payload and the same happens: that is the signature doing its job.

Common claims and what they mean

The registered claims are defined in RFC 7519. sub is the subject, usually a user ID. iss names the issuer and aud the intended audience; a service should reject tokens meant for someone else. exp, nbf and iat are Unix timestamps in seconds. Anything else in the payload is a custom claim chosen by the application, such as roles or a tenant ID.

Security mistakes to avoid

Never put secrets or personal data in a JWT payload unless the token is also encrypted; it is readable by anyone. Always verify the signature on the server before trusting any claim, and reject tokens with alg none or an algorithm your service did not expect. Libraries that let the token choose its own algorithm have caused real breaches.

HMAC secrets must be long and random. A short or dictionary-word secret can be brute-forced offline from a single captured token, which lets an attacker mint valid tokens of their own.

What this tool does not verify

Tokens signed with RSA or elliptic-curve keys (RS256, ES256, PS256 and similar) are decoded, but their signatures are not checked here, because that needs the issuer's public key. Verify those in your backend with the issuer's published keys.

Questions

Is it safe to paste a real token here?

Decoding and verification run in your browser and nothing is sent. Still, a live token is a credential: anyone who sees it can use it until it expires. Prefer expired or test tokens.

Why is my token reported as malformed?

A JWT needs exactly three parts separated by dots, and the first two must decode to JSON. Copying a token with a Bearer prefix, a line break or quotes around it is the usual cause.

Can a JWT be revoked?

Not by itself. It stays valid until exp unless the server keeps a deny list, which is why access tokens are usually short-lived.