JWT Decoder
Decode JWT header and payload so you can inspect claims quickly, without confusing decode with verification.
Decode a token to view the header…Decode a token to view the payload…What this tool is actually for
This page is useful when auth is failing and you need to inspect the token structure fast. It is not a trust decision engine.
Reads header and payload (Base64URL → JSON) so you can inspect exp, aud, iss, scopes, and custom claims.
Verification validates the signature against a key. This page does not verify signatures.
Before you blame the signature
A lot of JWT incidents are not cryptographic failures. They are bad assumptions about time, audience, issuer, or token shape.
- Remove “Bearer ” prefix if present.
- Check exp and convert it to a date (seconds vs ms).
- Validate iss/aud match your API configuration.
- Confirm algorithm in header matches what you expect.
- Check whether nbf or iat are invalid because of clock skew.
What decoding will never prove
This distinction matters because many teams lose time reading payloads and assuming the token is valid.
A readable payload is not a trusted payload. Anyone can craft a token-like string that decodes cleanly.
Even with a valid signature, the token may still be wrong for your API, environment, or tenant.
Treat real tokens as sensitive. Avoid pasting production tokens when screen sharing or when your environment is not fully trusted.
Typical failure patterns
These are the real reasons many “JWT problems” end up being app configuration problems.
The token came from staging but is being sent to production, or vice versa. The payload often gives that away immediately through iss, aud, or tenant-specific claims.
exp, iat, and nbf are frequently misread because teams mix seconds and milliseconds or because server clocks drift.
The token may be valid, but still missing the role, scope, or audience required for the endpoint that failed.
Related tools and reading
Use these when the token is only one piece of a larger auth or payload debugging problem.