Free tool · no signup

JWT decoder

Paste a JSON Web Token to read its header and payload, see when it expires, and get warned about settings that attackers abuse. It runs in your browser and never uploads the token.

By the Bug Circuit security team · Last updated

What is inside a JWT? Three base64url parts separated by dots: a header (the signing algorithm), a payload (claims such as who the user is and when the token expires) and a signature. The first two are only encoded, not encrypted, so anyone holding the token can read them.

How it works

How a JWT is built

A JSON Web Token (RFC 7519) is the header, the payload and the signature, each base64url encoded and joined with dots. The header says how the token is signed (alg). The payload holds claims: sub (the subject), iss (the issuer), aud (the audience), iat (issued at), nbf (not before) and exp (expiry), plus anything the application adds. The signature proves the first two parts were not changed.

This tool decodes the first two parts so you can read them and shows the times in plain dates. It cannot verify the signature, because that needs the key. Always verify signatures on the server.

What the checker flags

It warns about alg none (an unsigned token that a careless server may accept), an empty signature, tokens with no exp or a very long lifetime, expired tokens, missing iss and aud, and header fields such as jku, x5u, jwk and x5c that let a token point at its own verification key. It also warns when a payload contains words such as password or secret, because the payload is readable by anyone.

A short-lived token and strict server-side checks of the algorithm, issuer, audience and expiry are what make JWTs safe. Most real-world JWT vulnerabilities are mistakes in that verification code.

Handling tokens safely

Treat a live token like a password: anyone who has it can act as the user until it expires. This page decodes locally and sends nothing, but as a habit, use expired or test tokens when you share an example, and store login tokens in an HttpOnly cookie rather than somewhere a script can read.

Worked examples

Reading a normal token

Header {"alg":"HS256","typ":"JWT"}, payload with a subject and an issued-at time.

{
  "sub": "1234567890",
  "name": "Example User",
  "iat": 1516239022
}

The decoder shows the claims as JSON and the iat as a readable date. It also notes that there is no exp, so the token never expires.

A dangerous header

A token whose header says alg none.

{ "alg": "none", "typ": "JWT" }

Critical. Servers must reject unsigned tokens. If yours accepts this, anyone can forge any identity.

Frequently asked questions

Is a JWT encrypted?
A normal signed JWT is not encrypted, only encoded. Anyone with the token can read the payload, so never put passwords or secrets in it.
Can this tool verify the signature?
No. Verifying needs the secret or public key, which you should keep on your server. This page only reads the token and checks its settings.
What does alg none mean and why is it dangerous?
It means the token is not signed. If a server accepts such tokens, an attacker can write any claims they like. Servers must require a signature and fix the allowed algorithms.
How long should a JWT live?
Access tokens should be short, from a few minutes to an hour. Use a separate refresh token, stored more carefully, for longer sessions, and rotate it.
Where should I store a JWT in a browser?
In an HttpOnly, Secure, SameSite cookie, so scripts cannot read it. Local storage is readable by any injected script.
Is it safe to paste a real token here?
The tool decodes it locally and does not send it anywhere. Still, a live token is as sensitive as a password, so prefer test or expired tokens when you can.

Keep reading

See what attackers see, for free

Run the free passive check on your website. No login, no impact on your site, results in seconds.

Ready for the full manual audit? See pricing

JWT Decoder and Security Checker · Bug Circuit