JWT Debugger
Fast, accurate, and free online JWT Debugger tool that runs directly in your browser.
-
1Enter data
Enter content, paste text or load a file from disk. -
2Click the button
The tool will immediately process your data in the browser. -
3Get the result
Copy the finished text or save the file to your device.
return "Result ready in 0.1s";
}
Rate this tool:
Related tools
Other tools you may find usefulJWT (JSON Web Token) debugger - decode, check and catch errors before production
Do you have a JWT token from an application, logs or Authorization header and want to see what's really inside in 10 seconds? This debugger breaks down the JWT into header, payload and signature, shows the dates (exp/iat/nbf), evaluates the temporal status and - if you want - verifies the signature for HSxxx or RSxxx.
JWT is a convenient standard, but also a classic generator of "silent problems": the token looks correct, but logging in does not work, the API shouts 401, permissions are inconsistent or the date sunset is set in space. The JWT debugger is there to take the guesswork out of you. You paste the token, click "Decode" and immediately see the structure, metadata and potential mines.
What you get immediately after decoding
The tool shows the decodedheader i payloadin readable JSON, extracts key fields (alg, type, kid) and interprets timestamps:exp(when expires),iat(when issued),nbf(from when it will be valid).
Additionally, you get a time status (OK / expired / not yet active), as well as simple metrics: the size of the whole and the lengths of individual parts. This makes it easier to quickly compare tokens and spot "strangely" inflated payloads.
Signature verification when you need confidence
JWT decoding does not mean the token is trusted. Anyone can paste any JSON into payload and encode it with Base64URL. Therefore, the debugger has theoption to verify thesignature: for HMAC (HS256/384/512) you specify the secret, and for RSA (RS256/384/512) - the public key.
Thanks to this, you can quickly check whether the problem is an incorrect secret/key, a confused algorithm, an error in generating the signature or a token replacement along the way.
How to use the JWT debugger step by step (without philosophy)
Most often it looks like this: you get a token in the header, in a cookie or in the logs and you want to "see the truth". Do it in this order - it works for both tokens from your backend and those from external providers.
- Paste the JWT token into the field (must have 3 parts separated by dots).
- Click "Decode Token" and view the header + payload in JSON.
- Check the time status: whether the token has not expired and whethernbfis not blocking it "before start".
- If this is a token trust issue: check "Verify signature" and provide secret (HS) or public key (RS).
- Take a look at the security audit - sometimes the tool immediately tells you what is suspicious.
What exactly is inside a JWT and what to look at first
A JWT consists of three elements:header, payload i signature. The header tells how the token is signed (e.g. alg), the payload carries data (claims), and the signature is to guarantee that the content has not been changed.
Header: alg, type and sometimes mysterious kid
The most important field isalg- signature algorithm. If you seenonethere, then a red flag goes off: such a token should not be accepted in any serious scenario. Thefield typeis usually "JWT", andkidis sometimes used to indicate a specific key (e.g. in key rotation environments).
Payload: claims, roles, IDs and "time"
Payload often includes user IDs, role names, permissions, as well as standard claims likeexp, iat, nbf. The debugger will show them in JSON and immediately convert them to a readable date, so you don't have to manually recalculate timestamps.
Most common scenarios: how you will know that the token is pretending to be valid
The token is temporarily OK, but the API rejects it. Usually it's a bad signature, a bad issuer/audience, or claims that don't match the authorization rules.
Exp is in the past. In practice, the culprit is often the time difference between servers or too short TTL in the configuration.
NBF set for the future. Common in integrations and test environments where clocks are not synchronized.
'none' or unsupported algorithm. This is not always an error, but always a subject for verification on the backend side.
For HMAC, short secrets are tempting because "it works". But security can then collapse like a house of cards.
The token swells because someone puts too much data into claims. This increases the risk of leaks and problems with HTTP headers.
JWT algorithms in practice: what requires a secret, what requires a key, and what is suspicious
| Algorithm | Family | For verification you need | Typical use | The most common failure |
|---|---|---|---|---|
| HS256 / HS384 / HS512 | HMAC | Secret (shared) | Own API, monoliths, simple integrations | Secret too short, environment error (dev/prod) |
| RS256 / RS384 / RS512 | RSA | Public key | Integrations, SSO, key rotation, larger systems | Wrong key format pasted, wrong key-id |
| none | No signature | — | In principle: you should not use | Accepting a token without a signature (critical) |
Mini-checklist: what to check before you consider a token "faulty"
Sometimes the token is OK, but the context on the application side is different than you think. This checklist saves you a lot of nerves.
- Does the JWT have exactly 3 parts separated by dots (header.payload.signature)?
- Isn't exp in the past and are the servers time synced?
- Does nbf not block the token "before the start"?
- Does the alg in the header match what the backend expects?
- Is the signature verified on the correct secret/public key?
- Does the payload contain data that should not be in the token (e.g. sensitive)?
JWT security without scaring you: what does this debugger pay attention to
The tool does not pretend to be a full security scanner, but it can catch things that make a difference in real projects. For example: algorithmnoneis a red alert. In addition, there are practical warnings for HMAC when a secret is suspiciously short - because brute force or configuration leaks happen more often than we would like.
The most important thing is the approach:decodingis preview,verificationis trust. If you want to be sure that the token has not been replaced, always use the signature verification option.
FAQ - Questions that always come up
Is JWT decoding safe? Is my token "wandering" somewhere?
JWT decoding involves reading data encoded in Base64URL, so it does not require any codebreaking or "magic" in itself. From the user's point of view, one thing is important: paste tokens consciously. If the token gives you access to an account or API, treat it like a password - don't share it publicly or send it to places you don't trust.
Why do I see the payload but the signature doesn't match?
This is a classic. Payload can always be read because it is not encrypted (JWT is usually a signed token, not encrypted). If the signature does not pass, the reasons are usually simple: wrong secret (HS), wrong public key (RS), wrong algorithm in the header, or the token was changed along the way (e.g. accidental spaces, truncation of a fragment, substitution of characters).
The token is "temporarily valid" and the application returns a 401 anyway - what next?
If the time is correct, you go to the "context": issuer (iss), audience (aud), scope/role/permissions, and the way the backend maps claims. Often the token is cryptographically correct, but does not match the expected "profile" (e.g. different aud, different environment, different provider).
What do exp, iat and nbf mean in practice?
iatis the moment of token issuance,expis the moment of expiry, andnbfis the moment from which the token is to be considered valid. Most often you look at exp (whether it has not expired) and nbf (if it is not set in the future). The debugger shows these values as dates so you don't have to recalculate timestamps manually.
What is the difference between HS256 and RS256 and what to choose?
HS256 uses a shared secret - the same value is used for signature and verification. RS256 is based on a pair of keys: private signs, public verifies. In practice, HS tends to be simpler in a single system, and RS scales better in integrations and multi-service environments where you don't want to distribute the secret to everyone.
Why is "alg: none" a problem?
Because it means no signature. If the system accepts "none" alg tokens, someone can take any payload (e.g. elevate the role to admin), encode it and provide it as a "token" without any cryptographic protection. The debugger flags this as a critical warning because the consequences can be immediate.
If you want: use the debugger now
Paste the token, decode and see what's inside it. And if the matter concerns security or integration - run signature verification and base the topic on facts, not guesses.
Open JWT Token Debugger