What's the difference between iat and exp in JWT?

iat (issued at) is when the JWT was created. exp (expiration) is when it becomes invalid. The difference is the token lifetime. Check if exp is less than current time to determine if token is expired.

Why does JWT have three parts separated by dots?

JWT format is header.payload.signature. Each part is Base64Url-encoded. Header contains metadata, payload contains claims, and signature proves the token wasn't tampered with. This structure makes JWTs self-contained and stateless.

Decode JWT Online

Q: Does decoding verify the JWT signature?

No, this decoder only decodes the Base64-encoded header and payload—it does not verify the cryptographic signature. Signature verification requires the secret key (for HS256) or public key (for RS256), which should never be exposed in a browser tool. Decoding is useful for debugging and inspecting token contents, but you must verify signatures on your backend before trusting a JWT. Never use decoded JWT data for authorization decisions without first validating the signature server-side using a library like jsonwebtoken (Node.js) or PyJWT (Python).

Q: What's the difference between iat and exp?

iat (issued at) is the Unix timestamp when the JWT was created. exp (expiration) is the Unix timestamp when the token becomes invalid. The difference between them is the token's lifetime. For example, if iat = 1704067200 (Jan 1, 2024 00:00:00) and exp = 1704153600 (Jan 2, 2024 00:00:00), the token is valid for 24 hours. To check if a token is expired, compare exp to the current Unix timestamp. If exp is less than Date.now() / 1000 , the token is expired and should be refreshed.

Q: Can I decode JWTs from any authentication provider?

Yes, this decoder works with JWTs from any provider (Auth0, Firebase, Cognito, Okta, custom auth servers) because JWT is a standard format (RFC 7519). All JWTs follow the same structure: header.payload.signature, where header and payload are Base64Url-encoded JSON. The decoder simply Base64-decodes these parts to show the JSON contents. However, custom JWT implementations may include non-standard claims or use proprietary header fields, which will still decode but may require provider documentation to interpret correctly.

Q: Why does my JWT have three parts separated by dots?

JWT format is header.payload.signature , where each part is Base64Url-encoded and separated by dots. The header contains metadata (algorithm, token type), the payload contains claims (user data, expiration), and the signature is a cryptographic hash that proves the token wasn't tampered with. This three-part structure allows the token to be self-contained and stateless—servers can verify tokens without database lookups by checking the signature against a secret or public key. If your token has fewer or more than 3 parts, it's not a valid JWT and may be a different token format like an opaque token or session ID.

Decode and inspect JSON Web Tokens (JWT) instantly in your browser. View header, payload, and signature to debug authentication issues, verify claims, and inspect token expiration without backend tools or libraries.

Why Use JWT Decoder Online

JWT tokens are Base64-encoded strings that look like gibberish until decoded. When debugging authentication failures, expired tokens, or incorrect claims, you need to inspect the token's contents quickly. This decoder reveals the header, payload, and signature so you can verify issuer, expiration, user ID, and custom claims instantly.

Instant decoding: Paste JWT and see decoded header + payload immediately
Claims inspection: View exp, iat, sub, aud, iss, and custom claims
Expiration check: See if token is expired and when it was issued
No verification: Decodes without validating signature (inspect-only mode)
Browser-safe: All decoding happens locally—no server uploads

Decode JWT Now →

Choose the Right Variant

This page: Quick JWT decoding for debugging and inspection
JWT Token Decoder: Decode JWT access and refresh tokens
JWT Parser: Parse JWT with detailed claim analysis
Decode JWT: Fast JWT header and payload extraction

Step-by-Step Tutorial

Copy the JWT token from your app, API response, or browser cookie
Example JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Paste the token into the decoder input field
The decoder splits the JWT into three parts: header, payload, signature
Inspect the decoded payload to see claims like sub (user ID), exp (expiration), iat (issued at)
Check if exp timestamp is in the past (token expired) or future (still valid)

JWT Structure & Claims

Header: Contains algorithm (HS256, RS256) and token type (JWT)
Payload: Contains claims (user data, expiration, issuer)
Standard claims:
iss - Issuer (who created the token)
sub - Subject (user ID the token represents)
aud - Audience (intended recipient)
exp - Expiration time (Unix timestamp)
iat - Issued at (Unix timestamp)
nbf - Not before (token not valid until this time)
Custom claims: Application-specific data (roles, permissions, email)
Signature: Cryptographic signature to verify token hasn't been tampered with

Real-World Use Case

A frontend developer gets a "401 Unauthorized" error when calling an API. The API expects a valid JWT in the Authorization header. They copy the JWT from the browser's network tab, paste it into the decoder, and immediately see the payload shows "exp": 1704067200 (January 1, 2024). Converting the Unix timestamp reveals the token expired 6 months ago. The issue: the refresh token logic isn't working, so users keep using expired tokens. They fix the refresh flow, test with a fresh token, and the API returns 200 OK. Total debugging time: 2 minutes instead of 30 minutes adding debug logs to the backend.

Best Practices

Check exp claim first when debugging authentication failures
Verify iss (issuer) matches your auth server domain
Confirm aud (audience) includes your API's identifier
Check sub (subject) contains the expected user ID
Look for custom claims like roles, permissions, or scope
Never trust decoded JWT contents without signature verification in production

Performance & Limits

Token size: Decodes JWTs up to 100 KB (typical tokens are 1-5 KB)
Processing speed: Instant decoding (< 10ms) for standard tokens
Large tokens: Tokens with hundreds of custom claims decode in < 100ms
Browser support: Works in all modern browsers
Offline mode: Fully functional offline after page loads

Common Mistakes to Avoid

Trusting decoded content: Decoding doesn't verify signature—anyone can create a JWT with fake claims
Ignoring expiration: Always check exp timestamp before trusting token
Wrong timestamp format: JWT timestamps are Unix seconds, not milliseconds
Missing parts: Valid JWTs have 3 parts (header.payload.signature) separated by dots
Signature confusion: Decoder shows signature but doesn't validate it—validation requires secret key

Privacy and Data Handling

All JWT decoding happens locally in your browser using JavaScript Base64 decoding. Your tokens never leave your device and are never transmitted to any server. However, JWT tokens often contain sensitive user information (user IDs, emails, roles) in the payload. Anyone with a JWT can decode it and read the claims—JWTs are not encrypted, only signed. Never include sensitive data (passwords, credit cards, SSNs) in JWT payloads. For maximum security, decode JWTs in private browsing mode when working with production tokens.

Frequently Asked Questions

Does decoding verify the JWT signature?

No, this decoder only decodes the Base64-encoded header and payload—it does not verify the cryptographic signature. Signature verification requires the secret key (for HS256) or public key (for RS256), which should never be exposed in a browser tool. Decoding is useful for debugging and inspecting token contents, but you must verify signatures on your backend before trusting a JWT. Never use decoded JWT data for authorization decisions without first validating the signature server-side using a library like jsonwebtoken (Node.js) or PyJWT (Python).

What's the difference between iat and exp?

iat (issued at) is the Unix timestamp when the JWT was created. exp (expiration) is the Unix timestamp when the token becomes invalid. The difference between them is the token's lifetime. For example, if iat = 1704067200 (Jan 1, 2024 00:00:00) and exp = 1704153600 (Jan 2, 2024 00:00:00), the token is valid for 24 hours. To check if a token is expired, compare exp to the current Unix timestamp. If exp is less than Date.now() / 1000, the token is expired and should be refreshed.

Can I decode JWTs from any authentication provider?

Yes, this decoder works with JWTs from any provider (Auth0, Firebase, Cognito, Okta, custom auth servers) because JWT is a standard format (RFC 7519). All JWTs follow the same structure: header.payload.signature, where header and payload are Base64Url-encoded JSON. The decoder simply Base64-decodes these parts to show the JSON contents. However, custom JWT implementations may include non-standard claims or use proprietary header fields, which will still decode but may require provider documentation to interpret correctly.

Why does my JWT have three parts separated by dots?

JWT format is header.payload.signature, where each part is Base64Url-encoded and separated by dots. The header contains metadata (algorithm, token type), the payload contains claims (user data, expiration), and the signature is a cryptographic hash that proves the token wasn't tampered with. This three-part structure allows the token to be self-contained and stateless—servers can verify tokens without database lookups by checking the signature against a secret or public key. If your token has fewer or more than 3 parts, it's not a valid JWT and may be a different token format like an opaque token or session ID.