A token can decode successfully and still be unsafe to accept. The JWT decoder helps you inspect its structure; your application must separately decide whether the token is authentic and appropriate for the request. Use a synthetic token while learning instead of copying a production access token into a debugging workflow.
Understand the three parts
A compact signed JWT normally has a header, payload and signature separated by periods. The header and payload use Base64url encoding. This is readable encoding, so those sections are not a place to hide passwords or other secrets. Encrypted JWTs have a different compact structure.
The header describes the signing algorithm. The payload contains claims: statements such as a subject identifier, issuer, audience or expiration time. The signature protects the signed content when it is checked with the correct key and algorithm policy.
Build a deliberately unsigned test example
Run this in your browser console to construct a small inspection example:
const encode = value => btoa(JSON.stringify(value))
.replace(/=/g, '').replace(/\+/g, '-').replace(/\//g, '_');
const header = { alg: 'none', typ: 'JWT' };
const payload = { sub: 'demo-user', iat: 1704067200, exp: 1704070800 };
const demoToken = `${encode(header)}.${encode(payload)}.`;
console.log(demoToken);This example uses ASCII values and has no signature. It is deliberately unsuitable for authentication. Paste it into the decoder and compare the displayed claims with the object above. If the inspector rejects unsigned input, use the built-in sample to inspect a signed structure instead. Neither example is a credential.
For a production encoder, handle UTF-8 correctly and use a maintained JWT library rather than this demonstration function.
Read the date claims correctly
iat indicates when a token was issued. exp indicates its expiration boundary, while nbf, when present, describes when use may begin. These JWT NumericDate values use seconds. Open the Unix timestamp converter to inspect them as UTC dates.
In the example, the issued time is 2024-01-01 00:00 UTC and the expiration time is one hour later. It is an expired demonstration token. Do not “fix” a signed token by editing its expiry claim: changing signed content breaks its signature.
Keep inspection and acceptance separate
Use the decoded display to diagnose missing claims, wrong units or unexpected values. In the application, verify the signature using trusted key material, permit only the algorithms required by your protocol, and enforce the expected issuer, audience and time checks. Also apply the authorization rules for the specific action.
An untrusted header must not be allowed to choose an arbitrary verification policy. A successful signature result from a debugging tool also does not demonstrate that the application's issuer or audience checks are correct.
The JWT standard, RFC 7519, defines the registered claims. Its companion security guidance, RFC 8725, describes validation pitfalls. Follow the documentation for the library and protocol used by your application.
Common debugging mistakes
- Remove the
Bearerprefix before pasting a token into an inspector that expects the token alone. - Avoid line breaks or surrounding quotation marks copied from a log.
- Check seconds versus milliseconds before diagnosing a date problem.
- Treat decoded claims as untrusted until validation completes.
- Avoid sharing tokens in screenshots, issue reports or copied URLs.
Use the JSON formatter to read a copied test payload and the Base64 tool to learn encoding concepts. Ordinary Base64 and Base64url use different conventions, so choose a decoder suited to the actual input.