Skip to content
TabBench

JWT Decoder

Decode JSON Web Tokens, see every claim explained and whether the token has expired, verify the signature with a secret or public key, and create test tokens.

Runs in your browser. Nothing you add is uploaded.

What the JWT Decoder does

A JSON Web Token is three Base64URL-encoded segments separated by dots: a header describing the signing algorithm, a payload of claims, and a signature. The first two are readable by anyone — a JWT is signed, not encrypted. This tool decodes the header and payload, explains every claim in plain words, shows whether the token is valid, expired or not yet valid, and verifies the signature when you give it the secret or the issuer's public key (HS, RS, PS, ES and EdDSA algorithms, with PEM, JWK or JWKS keys). It can also create and sign test tokens. Everything happens in your browser with its built-in Web Crypto; tokens and keys are never sent anywhere.

How to decode and verify a JWT

  1. Paste the token. A “Bearer ” prefix, quotes or line breaks copied along with it are ignored.
  2. Check the status: whether it has expired or isn't valid yet, when it was issued and how long it lasts.
  3. Read the claims table — each value is explained, and times are shown as dates in your time zone.
  4. To confirm it's genuine, enter the secret (for HS256) or paste the issuer's public key or JWKS (for RS256, ES256 and others). A matching signature proves the token hasn't been changed.
  5. To make a test token instead, switch to Create a token, edit the claims and sign it with a secret or a generated test key.

The JWT Decoder runs entirely in your browser — nothing you enter is uploaded, stored, or logged.

When to use it

Diagnosing 401 responses

When an API rejects a token, decoding it usually explains why immediately: the 'exp' claim is in the past, or the 'aud' does not match the service you are calling.

Verifying what an identity provider actually issues

OIDC providers vary in which claims they include. Decoding a real token is faster than reading the documentation to find out whether email or roles are present.

Checking token lifetime during development

Comparing 'iat' and 'exp' shows the configured lifetime, which is useful when a session expires sooner than expected.

Good to know

  • 'exp' and 'iat' are seconds since the Unix epoch. Multiply by 1000 before passing them to JavaScript's Date constructor.
  • An 'alg' value of 'none' is a red flag — it indicates an unsigned token, which no production verifier should accept.
  • Decoding is not verification. A decoded token that looks correct may still have an invalid signature.
  • Never paste a production token belonging to a real user into an online decoder that sends data to a server. This one does not.

Frequently asked questions

Is it safe to paste JWT tokens here?

Yes, decoding is performed purely in client JavaScript with no network requests.

Does decoding a JWT verify its signature?

No, and this is the most important thing to understand about JWTs. Decoding only reverses the Base64URL encoding of the header and payload; anyone can do it. Verifying the signature needs the issuer's secret or public key. You can check it here with that key, but your servers must always verify every token themselves — a token can decode perfectly and still be forged.

Is it safe to paste a token here?

Decoding runs entirely in your browser and the token is never transmitted. That said, treat any live token as a credential — anyone holding it can act as that user until it expires, so avoid pasting production tokens into tools generally, and revoke any token you suspect has been exposed.

Why is my JWT payload readable by anyone?

Because signed JWTs are designed for integrity, not confidentiality. The signature proves the payload was not altered; it does not hide it. Never place passwords, full card numbers, or other secrets in JWT claims. If you need confidentiality, use JWE rather than JWS.

What do the standard claim names mean?

'iss' is the issuer, 'sub' the subject (usually a user id), 'aud' the intended audience, 'exp' the expiry time, 'nbf' the earliest valid time, 'iat' the issue time, and 'jti' a unique token id. Anything else is a custom claim defined by whoever issued the token.

Why does my token have only two segments?

An unsecured JWT with 'alg: none' has an empty signature, producing a trailing dot with nothing after it. More often, a two-segment token means the string was truncated in transit — check for a length limit in whatever logged or copied it.

Related tools