JWT (JSON Web Token) consists of three Base64-encoded parts separated by dots: header.payload.signature. This decoder displays the decoded header and payload content. Note: This tool does not verify the signature—use server-side validation for security-critical operations.
Share
What is the JWT Decoder?
A JWT (JSON Web Token) is a compact, URL-safe string that encodes claims (data) in three base64-encoded parts separated by dots: header.payload.signature. The decoder splits this string, decodes each part, and displays the JSON data in a readable format so you can see what information is actually stored in your tokens.
How it works
The JWT decoder works by splitting the token at each dot separator to extract the three components. It then base64-decodes the header and payload sections and displays them as formatted JSON. The signature section remains encoded because it's cryptographic proof that the token hasn't been tampered with—you can't validate it without the secret key, but you can still see what's signed. Paste your token, and the tool instantly reveals all readable claims.
Reveals an unsigned token (alg: none) that is cryptographically insecure and should never be used
How to use the JWT Decoder
Copy your JWT from your application, browser DevTools, or API response—it looks like a long string with two dots
Paste the entire JWT into the input field
Click Decode and instantly see the header, payload, and signature sections formatted as JSON
Review the algorithm (alg) to confirm it's expected for your use case
Check the payload claims to verify user ID, permissions, expiry time, and other data
Use the decoded information to debug authentication failures or understand what the token contains
Benefits
Instantly inspect token contents without manually base64-decoding—saves time during debugging
Verify that claims (user ID, role, expiry) match what your application expects
Detect unsigned tokens (alg: none) or weak algorithms before they cause security issues
Understand the structure of OAuth 2.0, OpenID Connect, and API authentication tokens
Troubleshoot login and API access problems by examining token payload data
Tips & common mistakes
Common mistakes
Pasting a token and thinking the signature validates it—JWTs are NOT valid just because they decode; only cryptographic verification proves integrity
Trusting unsigned tokens (alg: none) or assuming they can't be forged—always validate the signature with the issuer's key
Assuming an expired token (exp claim in the past) is invalid without checking—the server should reject it, but the token itself is still decodable
Sharing tokens in URLs, chat, or version control—tokens are bearer credentials and should be treated like passwords
Tips
Check the exp (expiration) field to see when a token stops being valid—if it's in the past, the token has expired
Use the kid (key ID) field in the header to identify which public key was used to sign the token, helpful for key rotation
Look for custom claims (non-standard fields) in the payload that your application added—they appear alongside standard claims
If decoding fails, ensure you have the complete token with all three parts (header.payload.signature); even one missing dot breaks it
Frequently asked questions
Is decoding a JWT the same as validating it?
No. Decoding reads the claims but does not verify the signature. Validation requires cryptographic verification with the issuer's secret or public key. Always validate JWTs received from external sources before trusting them.
Can I use this decoder offline?
Yes, JWT decoding is client-side—no server is needed. Your token never leaves your browser, so it's safe to decode sensitive tokens locally.
What if the token is malformed or invalid base64?
The decoder will display an error showing which part failed to decode. Check that you've copied the entire token exactly and that it contains exactly two dots separating three parts.
Can I see what the signature is?
The signature is displayed in base64 form, but it's cryptographic proof of authenticity—decoding it visually doesn't reveal anything meaningful. Only the issuer's secret or public key can verify it.
What are common JWT claims I should understand?
Standard claims include: iss (issuer), sub (subject/user ID), aud (audience/app), exp (expiration time), iat (issued at), and nbf (not before). Custom claims depend on your app.
Is it safe to decode JWTs that contain passwords or PII?
JWTs are base64-encoded, not encrypted—anyone can decode them and see all claims. Never store passwords, credit cards, or highly sensitive PII in token payloads.