Developer Tools guide
JWT decoding vs verification: what can you safely conclude?
Suppose a JWT payload says the user is an admin and shows an expiry tomorrow. You have learned what the token claims. You have not yet learned whether a trusted issuer created it, whether it was intended for your service, or whether your application should grant admin access.
Level 1 — decoding tells you what the token claims
A common signed JWT has a header, payload and signature separated by dots. The first two parts are encoded JSON. They can usually be decoded without a secret because encoding is not encryption. The signature is not recovered by reading the header and payload.
SnakTool’s decoder reads supported three-part tokens and displays the decoded content. It does not verify a signature. Five-part encrypted tokens are a different structure and are not handled as though they were ordinary readable signed tokens.
Level 2 — verification needs trusted context outside the token
A trusted verifier needs the correct key and an allowed algorithm policy. It also needs to check claims such as issuer and audience against what the application expects. A token’s own declaration of an algorithm or issuer is untrusted input, not sufficient authority to choose a permissive verification path.
Expiration and not-before values are commonly NumericDate values in seconds. A readable date helps troubleshooting, but a token that is within its time window can still be invalid for other reasons. Clock handling and accepted leeway belong to the verifying system.
Level 3 — issuer and audience connect the token to your application
A verifier should compare the claimed issuer with an issuer it trusts and the audience with the service or resource expected to receive the token. A correctly signed token created for another application should not automatically be accepted by yours.
Expected issuer, audience, keys and allowed algorithms come from trusted configuration or the authentication system's documented setup, not from simply accepting whatever values the token contains.
Level 4 — time claims define a window, not authenticity
Claims such as exp and nbf commonly use NumericDate values in seconds from the Unix epoch. They help a verifier decide whether a validated token is inside its accepted time window.
A future expiry does not make a forged token valid. Likewise, an expired-looking value in an unverified token is still only an untrusted claim. Clock skew and accepted leeway belong to the verifying system's policy.
Level 5 — authorization happens after validation
Even a properly validated token does not automatically authorize every operation. Application policy still decides whether the verified identity, scopes, roles and resource context permit the requested action.
A visible role such as admin is therefore useful for debugging but unsafe as a standalone authorization signal.
Use inspection to ask better debugging questions
Check whether the intended audience matches the receiving application, whether times are in the expected unit and whether required claims are present. Compare against the authentication system’s documentation. Do not paste a production bearer token into a ticket simply because its payload appears harmless; possession may grant access.
Local decoding avoids a decoding-service upload, but the decoded content is still visible on your screen and clipboard if you copy it. Use a synthetic token when reporting a formatting issue. A displayed role such as admin should never be treated as authorization without trusted verification and application policy.
Classify the result before acting
- Check the expected issuer and audience with the application configuration.
- Compare time claims in seconds with the intended clock and policy.
- Perform signature and algorithm validation in the trusted application, not by reading the header alone.
- Use synthetic data in screenshots or support messages.
| Observation | What it establishes | What remains |
|---|---|---|
| Malformed token | This representation cannot be decoded here | Obtain the expected three nonempty segments; do not guess repaired credentials. |
| Readable claims | Header and payload JSON can be inspected | Signature, issuer, audience and application policy remain unverified. |
| Past exp value | The claimed expiry is in the past | A claim can be forged; decoding is not an authentication decision. |
| Future exp value | The claimed time has not passed | It does not establish authenticity or authorization. |