How it works
JWT decoding is not verification. The signature is not checked and the token may contain sensitive claims; use only safe test tokens.
Split token into three base64url segments and JSON-decode the first two.
Debugging scenario
Create a non-production token with the same header and claim shape as the failing request. Decode its algorithm, key identifier, issuer, audience, subject and time claims, then compare those values with the verifier configuration and server clock without exposing a real bearer credential.
How to interpret the result
Readable header and payload segments prove only that their Base64url content can be decoded as JSON. The signature is not verified. Claim names do not prove issuer identity, authorization, freshness or audience; all of those require a configured verification library and trusted key source.
Input reference
- JWT token
- Example default: Sample input included
Common mistakes
- Pasting secrets, credentials, customer records or other production data into a browser tool or shareable URL.
- Trusting alg, kid, roles, exp or any other decoded claim before cryptographic verification and policy checks.
- Treating a convenient preview as validation by the target runtime, parser, database or security control.
Before using the result
- Reduce the input to a synthetic example that still reproduces the behavior.
- Verify algorithm allowlists, signature, issuer, audience, time claims and key rotation in the application library.
- Add the accepted input and expected output to the project regression tests before release.
Questions to check before production use
Does this verify a JWT?
No. It only decodes readable segments; never treat the result as trusted.
Is my token stored?
No server upload is used, but the token can appear in the URL after running the tool. Use a test token.
Independent developer utility. Review output before using it in production.