What a JWT decoder shows
A JSON Web Token, or JWT, is a compact token format commonly used in authentication, authorization, API sessions, and identity workflows. A JWT usually has three dot-separated parts: a header, a payload, and a signature. The header and payload are base64url-encoded JSON, which means they can be decoded and read without a secret key.
This JWT decoder focuses on inspection. It formats the header and payload, extracts common claims, shows raw segments, and explains time-based claims such as iat, nbf, and exp. That is useful when debugging login flows, API calls, test environments, OAuth integrations, or token lifetime issues.
- Read the token algorithm and type from the header.
- Inspect issuer, subject, audience, and custom payload claims.
- Convert NumericDate claims into readable dates.
- Copy the decoded header, decoded payload, or raw token segments.
Decoding is not verification
Decoding a JWT tells you what the token says. It does not prove who created it, whether the payload was modified, whether the signature matches, or whether your application should accept it. Signature verification requires the correct secret, public key, or JWKS configuration and must match the algorithm expected by the application.
The signature part is different from the header and payload. It is a cryptographic value over the encoded header and payload, not another JSON object to decode. This page shows the signature in the raw segments output when it exists, but it does not ask for signing keys or verify the value.
Treat this page as an inspector, not an authority. A decoded token can still be fake, expired, unsigned, signed with an unexpected key, or rejected by the service that issued it.
Common JWT claims
| Claim | Meaning | Typical use |
|---|---|---|
iss | Issuer | The service or identity provider that issued the token. |
sub | Subject | The user, account, client, or entity the token is about. |
aud | Audience | The API, app, or service that should receive the token. |
iat | Issued at | When the token was created. |
nbf | Not before | The token should not be accepted before this time. |
exp | Expires at | The token should not be accepted after this time. |
Safe debugging habits
- Use test tokens whenever possible instead of production user tokens.
- Do not paste signing secrets, private keys, or API credentials into a decoder.
- Check that the algorithm is expected by your application.
- Compare
issandaudagainst the service you are debugging. - Remember that browser time and server time can differ when debugging expiry issues.
Related local tools
- Use the Base64 Encoder Decoder when you need to inspect ordinary base64 strings. JWTs use base64url, so this JWT decoder is still the safer fit for full tokens.
- Use the JSON Beautifier when you want to format copied payload objects outside the token context.
- Use the Unix Timestamp Converter when you need a dedicated timestamp check for NumericDate values such as
iat,nbf, orexp.
Frequently Asked Questions
Does this JWT decoder verify signatures?
No. It decodes the header and payload so you can inspect them, but it does not verify the signature or prove that the token is trusted. Verification requires the issuer's secret, public key, or JWKS configuration. The signature is not shown as a decoded JSON panel because it is a cryptographic value, not readable claims data; this tool shows it only in the raw segments output.
Can anyone decode a JWT?
Yes, the header and payload are encoded, not encrypted, unless your system uses a separate encrypted token format. Do not put secrets in JWT payloads.
What does an expired JWT mean?
If the exp claim is in the past, a server should normally reject the token. This page can show the timestamp, but the server is the final authority.
Why does the tool accept a Bearer prefix?
Developers often copy tokens from an Authorization: Bearer ... header. The tool removes the prefix before decoding the token body.