What is JWT Decoding?
JWT (JSON Web Token) decoding is the process of parsing a token to reveal its contents. A JWT consists of three Base64Url encoded parts: header, payload, and signature. Decoding converts these encoded strings back to readable JSON, allowing you to inspect the token's algorithm, claims, expiration time, and other metadata without needing to execute any code.
Why Use Our JWT Decoder?
- Secure & Private: All decoding happens in your browser - no data sent to servers
- Instant Parsing: Real-time decoding as you paste your token
- Visual Breakdown: See header, payload, and signature clearly separated
- Claims Table: View JWT claims in an organized, readable table format
- Signature Verification: Verify token authenticity with your secret or public key
- Algorithm Support: Works with HS256, RS256, and all standard JWT algorithms
Understanding JWT Structure
Header: Contains metadata about the token, primarily the signing algorithm (alg) like HS256 or RS256, and the token type (typ) which is usually JWT. The header is Base64Url encoded.
Payload: Contains the claims - statements about the user and additional data. Standard registered claims include sub (subject/user ID), iat (issued at timestamp), exp (expiration time), iss (issuer), aud (audience), and nbf (not before). You can also include custom claims specific to your application.
Signature: A cryptographic signature created by signing the encoded header and payload with a secret key (HMAC) or private key (RSA/ECDSA). The signature ensures the token hasn't been modified and verifies its authenticity.
Common JWT Decoding Use Cases
- Debugging Authentication: Inspect tokens to troubleshoot login issues and verify claims
- Token Inspection: Check expiration times, user IDs, and permissions without backend access
- API Troubleshooting: Examine tokens being sent to APIs to diagnose authentication failures
- Development Testing: Verify that your application generates tokens with correct claims
- Security Audits: Review token contents to ensure no sensitive data is exposed
- Learning & Education: Understand how JWTs work by examining real tokens
JWT Security Best Practices
1. Verify signatures server-side: Always validate JWT signatures on your backend before trusting the token's contents.
2. Check expiration times: Verify the 'exp' claim to ensure tokens haven't expired. Reject expired tokens immediately.
3. Validate claims: Check that required claims like 'iss' (issuer) and 'aud' (audience) match expected values.
4. Use HTTPS only: Never transmit JWTs over unencrypted connections. Always use HTTPS in production.
5. Don't trust decoded data: Just because you can decode a JWT doesn't mean it's valid. Always verify the signature.
6. Beware of algorithm confusion: Validate that the algorithm in the header matches what you expect to prevent downgrade attacks.
How to Read JWT Claims
sub (Subject): The user identifier, typically a user ID or username. This identifies who the token is about.
iat (Issued At): Unix timestamp when the token was created. Useful for determining token age.
exp (Expiration Time): Unix timestamp when the token expires. After this time, the token should be rejected.
iss (Issuer): Identifies who created and signed the token, usually a URL or identifier for your authentication server.
aud (Audience): Identifies the intended recipient of the token, typically your application or API.
nbf (Not Before): Unix timestamp before which the token should not be accepted. Useful for future-dated tokens.
Frequently Asked Questions
Can anyone decode my JWT?
Yes, JWTs are encoded but not encrypted. Anyone can decode a JWT to see its contents. This is why you should never include sensitive information like passwords or credit card numbers in a JWT payload. The signature prevents tampering, but the data is readable.
What's the difference between decoding and verifying?
Decoding simply converts the Base64Url encoded parts to readable JSON - it doesn't validate authenticity. Verification checks the signature using the secret or public key to ensure the token hasn't been modified and was signed by a trusted source.
Why does my JWT show as expired?
The 'exp' claim in the payload contains a Unix timestamp indicating when the token expires. If the current time is past this timestamp, the token is expired and should not be accepted for authentication.
Can I modify a JWT after decoding it?
While you can decode a JWT, modify its contents, and re-encode it, the signature will no longer be valid. Any system properly verifying JWTs will reject a modified token because the signature won't match the altered contents.
What should I do if signature verification fails?
Signature verification failure means either: (1) you're using the wrong secret/public key, (2) the token has been tampered with, (3) the token format is incorrect, or (4) there's an algorithm mismatch. Always reject tokens that fail signature verification.