Decode and verify
No network requestsWhat a JWT actually is
A JSON Web Token is three base64url strings joined by dots. The first is a header describing how the token was signed, the second is a payload of claims, and the third is a signature over the first two. It is defined in RFC 7519 (opens in a new tab).
The practical consequence is that "decoding" and "verifying" are two completely different operations, and only the second one tells you whether to trust the token.
Decoding is free
Splitting the token and base64url-decoding the first two segments requires no key and takes microseconds. That is what most online "JWT decoders" do, and it is why they can show you a payload without ever asking for a secret.
Verifying requires the key
The signature is an HMAC over the exact bytes of header.payload. To reproduce it you need the same secret the issuer used. Without it you can confirm the token is well-formed and unexpired, but you cannot confirm it is authentic.
"role":"user" to "role":"admin" and re-encodes the payload, the decode still succeeds and looks perfect. Only the signature check catches it — which is why verification must happen on the server, on every request, and never on the client.
The three segments
| Segment | Contains | Typical claims | Signed? |
|---|---|---|---|
| Header | Metadata about the token itself | alg, typ, kid, crit |
Yes, as part of the signing input |
| Payload | Claims about the subject | sub, iss, aud, exp, nbf, iat, jti, plus any custom keys |
Yes, as part of the signing input |
| Signature | The MAC or asymmetric signature | Not a JSON value; raw bytes in base64url | Is the signature |
Header claims worth reading
alg— the algorithm. This is the most security-critical field in the whole token, and also the most abused. A verifier must pin the algorithms it accepts rather than trusting this value.typ— almost alwaysJWT. Informational only; it is not validated by most libraries.kid— key identifier. Tells the verifier which key in a key set to use, which matters when a service rotates signing keys.crit— extensions the verifier must understand or reject. Rare, and easy to get wrong.
Registered claims and what to check
RFC 7519 defines seven claim names. They are not mandatory, but when present each has defined semantics that a verifier is expected to enforce.
| Claim | Meaning | What a verifier must do |
|---|---|---|
iss | Issuer | Compare against the expected issuer string exactly. |
sub | Subject | Identify the principal. Usually a user ID; treat as opaque. |
aud | Audience | Reject the token if your service is not in the audience. Skipping this lets a token minted for one service be replayed against another. |
exp | Expiration time | Reject once the current time is past it. This is the claim that bounds the damage of a stolen token. |
nbf | Not before | Reject before this time. Rare, but breaks badly when ignored on short-lived tokens. |
iat | Issued at | Use to reject tokens from the far future, and to compute token age. Allow for clock skew. |
jti | JWT ID | Use to detect replay of the same token, typically with a short-lived deny-list. |
All three time claims are NumericDate: seconds since the Unix epoch, not milliseconds. A token that uses milliseconds will appear to expire tens of thousands of years from now, and the mistake is easy to miss because the token still decodes.
How the signature check works here
The signing input is the exact string base64url(header) + "." + base64url(payload), using the original encoded segments from the token. Not the pretty-printed JSON, not a re-serialised object — the literal bytes the issuer signed. Any re-encoding changes the input and produces a false negative, which is the most common way a JWT verifier is written incorrectly.
Supported algorithms
| Algorithm | Key type | Verified here? |
|---|---|---|
HS256 | Shared secret | Yes — HMAC-SHA256 |
HS384 | Shared secret | Yes — HMAC-SHA384 |
HS512 | Shared secret | Yes — HMAC-SHA512 |
RS256, RS384, RS512 | RSA public key | No — decoded, signature not checked |
PS256, PS384, PS512 | RSA public key | No — decoded, signature not checked |
ES256, ES384, ES512 | EC public key | No — decoded, signature not checked |
none | No key | Flagged as unsigned — see the warning below |
Asymmetric algorithms need a public key rather than a secret, and importing one correctly — JWK versus PEM versus X.509, with the right curve parameters — is a larger surface than this tool attempts. Those tokens are still decoded and their claims are still checked; the verification panel says plainly that the signature was not verified, rather than implying it passed.
Web Crypto and secure contexts
Verification uses the browser's built-in crypto.subtle, which is only exposed over HTTPS or on localhost. On a plain HTTP origin the API is missing, and the tool says so instead of silently reporting a failure. Decoding and claim checks work regardless.
What the debugger flags
Decoding a token correctly is only half the job. The other half is telling you which parts of it are a problem.
algisnone— reported in red. The token is unsigned, and a server that honours this algorithm accepts any payload. Rejectnoneexplicitly in every verifier.- No
algat all — also red. A verifier should refuse a token that does not declare how it was signed. - Expired — shows how long ago, in human terms, as well as the exact timestamp.
- No
exp— the token never expires on its own. Only key rotation or explicit revocation ends its life. nbfin the future — the token is not valid yet; the tool states how long until it becomes usable.iatin the future — usually a clock skew problem between issuer and verifier.- A time claim that is not a number — some issuers emit ISO strings; libraries expect NumericDate and will reject or misinterpret them.
- Asymmetric algorithm — an informational note that the signature was not checked, so you do not mistake decoding for verification.
How to use the debugger
-
Paste the token
The whole string, including the signature. A leading
Bearerand any line breaks from a wrapped log line are stripped automatically. -
Read the header and payload
Both are shown as formatted JSON. The summary strip above them states the algorithm, whether the token is expired, and the token size.
-
Check the claims table
Every payload key is listed, with registered claims labelled and time claims rendered as readable dates alongside the raw epoch value.
-
Add the secret if you need verification
Only for HS256, HS384, and HS512. Paste the exact secret the issuer used — a trailing newline or a non-ASCII hyphen is enough to make a correct token look invalid. Use the Show button to inspect what you pasted.
-
Read the warnings before the results
The warnings list is the part that tells you whether to trust the token. A token can decode perfectly and still be unsigned, expired, or missing an audience.
What this tool cannot do
- It cannot verify asymmetric signatures. RS, PS, and ES tokens need a public key and are only decoded here.
- It cannot decrypt a JWE. A five-segment token is encrypted, and without the key its payload is unreadable by design.
- It cannot prove a token is accepted by your server. It checks the signature and the standard time claims. Audience, issuer, scope, revocation lists, and key rotation are all server-side policy this tool does not know about.
- It cannot detect a leaked or revoked token. Revocation is stateful and lives in your backend.
- It cannot tell you whether the secret is the right one. If verification fails, the tool knows the signature does not match; it cannot know whether the secret, the algorithm, or the token is the problem.
- It is not a security boundary. Verifying a token in a browser says nothing about whether your application verifies it correctly. That check belongs in a test suite against your real verifier.
Frequently asked questions
Does this tool send my token anywhere?
No. Decoding and verification run in JavaScript on your device. There is no API call and no analytics event containing the token. You can confirm this yourself: open the Network tab, clear it, and decode a token. No new request appears. The page also keeps working with the network disconnected after it loads.
Can anyone read the contents of a JWT?
Yes. The header and payload are base64url-encoded, not encrypted. Anyone holding the token can read every claim without a key, which is why a JWT must never contain passwords, card numbers, or other secrets. The signature proves the token was not altered; it does not hide the contents.
Why does signature verification need the secret?
The signature is computed over the header and payload with a key that only the issuer and verifier share. To check it, this tool has to reproduce that computation, so it needs the same secret. The secret is held in the input field in memory, is never written to storage, and disappears when you close or reload the page.
Which algorithms can be verified?
HS256, HS384, and HS512 — the HMAC family that uses a shared secret. RS, PS, and ES algorithms use a public key instead and are not verified here; those tokens are still decoded, and a note explains that the signature was not checked. Tokens declaring alg none are flagged as unsigned.
Why was my valid token reported as failing verification?
The most common causes are a secret with a stray space or newline, a secret that differs from the one the issuer used, or an algorithm mismatch such as selecting HS512 for a token signed with HS256. The algorithm is read from the token header, so it is chosen automatically. If the token was produced by a service, confirm the exact secret bytes rather than the value you expect them to be.
What does alg none mean?
It means the token carries no signature at all. A server that accepts alg none will accept any payload an attacker sends. Every verifier should reject that algorithm explicitly rather than defaulting to it. This tool shows a red warning whenever it sees it.
Can I paste a production token?
It is better practice not to paste live credentials into any web page, including this one. Even though the code runs locally and no request is made, you cannot audit every tool you meet. For a production token, prefer decoding it in your own terminal or test suite, and treat anything pasted into a browser tab as potentially exposed.
Does it support encrypted tokens?
No. A token with five dot-separated segments is a JWE, which is encrypted rather than merely signed. Without the decryption key its contents are unreadable by design, and this tool says so instead of guessing.
About this tool and how it is maintained
Editorial and verification standards are documented in our editorial policy. Data handling is described in the privacy policy.