Authentication debugging
Inspect issuer, audience, subject, roles and custom claims returned by an identity provider.
Developer Tools
JWT Decoder Online Free
Decode JWT tokens online and inspect the token header, payload, claims, expiry time and issued time. This JWT Decoder runs in your browser and helps developers debug authentication tokens safely.
Developer authority guide
Use JWT Decoder with confidence
Inspect the header, payload, timestamps and claims inside a JSON Web Token without sending the token to a remote service. This is useful while debugging authentication, API authorization and identity-provider integrations. Decoding does not prove that a token is genuine: signature verification still requires the correct key and expected issuer settings.
✓ Runs in your browser
✓ No account required
✓ Free developer utility
✓ Mobile and desktop ready
Practical use cases
Expiry investigation
Read exp, iat and nbf timestamps when troubleshooting tokens that are rejected too early or remain valid too long.
API integration review
Compare the claims an API expects with the claims actually present in a bearer token.
OAuth and OpenID Connect
Examine access and ID tokens during development without manually splitting token segments.
Recommended workflow
- 1
Paste the complete JWT, including both period separators.
- 2
Review the decoded header and identify the declared algorithm and token type.
- 3
Inspect the payload claims, especially issuer, audience, subject, roles and timestamps.
- 4
Treat the decoded data as untrusted until the signature and expected claims are verified by your application.
Developer correctness
Validate syntax, semantics and runtime assumptions
Developer utilities can transform representation without proving that the result is correct for a production system. Syntax, encoding, runtime-specific rules, schemas and security context all matter. Treat browser output as a fast inspection aid, then validate it in the target language, framework or deployment environment.
Syntax vs semantics
A value can be syntactically valid while still violating an API contract or business rule.
Encoding
Unicode, escaping and byte representation can change how data is interpreted across systems.
Runtime differences
Regex, date parsing, SQL and serialization behaviour can vary between engines and libraries.
Security context
Encoding, hashing and formatting do not replace validation, authorization or safe APIs.
What the operation can change
- Formatting should preserve values but may normalise whitespace.
- Minification removes presentation whitespace and can make debugging harder.
- Encoding changes representation, not trustworthiness or confidentiality.
- Generated code still needs review for naming, nullability and framework conventions.
Domain-specific verification
- Run the result through the destination parser or compiler.
- Test Unicode, empty values, nulls and deeply nested inputs.
- Compare behaviour against the production runtime and version.
- Never paste secrets, access tokens or confidential payloads into untrusted tools.
Engineering review
Prepare, verify and troubleshoot the result
Before using the tool
- ✓ Use a test token whenever possible.
- ✓ Remove the Bearer prefix before decoding.
- ✓ Confirm the token has three period-separated segments.
Before using the output
- ✓ Review issuer, audience, subject, roles and timestamps.
- ✓ Compare exp, nbf and iat against the server's UTC clock.
- ✓ Verify the signature and claims in the actual application before trusting the token.
ProblemPractical check
Token cannot be decodedCheck for missing segments, copied spaces or Base64URL characters damaged during transport.
Token appears valid but API rejects itCheck signature, issuer, audience, scope, clock skew and server-side authorization rules.
Timestamp looks wrongJWT times use Unix seconds, normally interpreted in UTC.
Implementation notes
- • Decoding is not signature verification.
- • JWT payloads are readable and should not contain passwords or confidential personal data.
- • The server must enforce approved algorithms instead of trusting the alg header.
Common mistakes to avoid
Assuming decoded means verified
Anyone can create a JWT-shaped string. Decoding only displays its content.
Sharing production tokens
Tokens may grant access to real systems. Use test tokens and remove secrets before sharing screenshots.
Ignoring clock skew
Small time differences between systems can affect exp and nbf validation.
Trusting the alg header blindly
The server must enforce approved algorithms rather than accepting whatever the token declares.
Professional tips
- ✓Use short-lived test tokens while debugging.
- ✓Validate issuer and audience as well as the signature.
- ✓Never put passwords or confidential personal data in JWT payloads.
- ✓Compare decoded Unix timestamps with the server's UTC clock.
Frequently asked questions
Can a JWT be decoded without the secret?
Yes. JWT headers and payloads are Base64URL encoded, not encrypted. The secret or public key is needed to verify the signature, not to read the visible claims.
Why does my token have three parts?
A signed JWT normally contains a header, payload and signature separated by periods.
What does the exp claim mean?
exp is the Unix timestamp after which the token must no longer be accepted.
What is the difference between an access token and an ID token?
An access token authorizes API access, while an ID token describes an authenticated user for the client application.
Is a JWT encrypted?
A normal signed JWT is not encrypted. Sensitive information should not be placed in its payload unless an encrypted token format is used.
Can this tool refresh an expired token?
No. Refreshing requires the authorization server and a valid refresh-token flow.