JWT Decoder & Expiry Calculator

The JWT Decoder & Expiry Calculator parses JSON Web Tokens (JWT, defined in RFC 7519) — the standard token format for stateless authentication in modern web APIs. It decodes the base64url-encoded header and payload, parses JSON claims, and analyzes time-based claims including expiration (exp), issued-at (iat), not-before (nbf), subject (sub), issuer (iss), and audience (aud). JWTs are used by OAuth2/OIDC providers (Auth0, Okta, AWS Cognito, Clerk, Firebase Auth, Supabase) and most modern session systems. A JWT consists of three base64url-encoded segments separated by periods: header.payload.signature. The header declares the signing algorithm (HS256, RS256, ES256 are common). The payload contains 'claims' — both standard claims (sub, exp, iat, nbf, iss, aud, jti) and custom application-specific data. The signature cryptographically binds header and payload using either an HMAC secret (HS256) or asymmetric key pair (RS256/ES256). The decoder shows header and payload contents but does NOT verify the signature — that requires the secret or public key and should always be done server-side before trusting any JWT. Understanding JWT structure is essential for debugging authentication issues, understanding what data flows between client and server, and verifying that tokens are properly formed. Common debugging scenarios: 'Why is my token rejected?' (usually expired or wrong audience), 'What user is this token for?' (check sub claim), 'When does this expire?' (exp claim), and 'What permissions does this user have?' (custom claims like roles, scopes, or permissions). This calculator handles the most common analyses: structure validation (3 parts, valid base64url), JSON parsing, expiration status (valid, expiring soon <7 days, expired), not-yet-valid handling (nbf in future), and human-readable display of all standard claims plus full header and payload JSON. The signature is shown but not verified — production verification should always use a JWT library (jsonwebtoken, jose, PyJWT, etc.) with the correct verification key.

DigiCalcs delivers precision-engineered tools for engineers and STEM professionals.

1. 1Step 1 — Paste Your JWT Token: Copy the full token (typically a long string starting with 'eyJ' since 'eyJ' is the base64url encoding of '{"' that starts the JSON header). Tokens are usually 100-2000+ characters long depending on payload size.
2. 2Step 2 — Token Structure Validation: Calculator splits the token on periods. A valid JWT has exactly 3 parts: header, payload, signature. If splits don't produce 3 parts, the token is malformed. Common causes: truncation during copy-paste, missing parts in API responses, or non-JWT tokens (some APIs use opaque tokens that aren't JWTs).
3. 3Step 3 — Base64url Decoding: Each part is base64url-decoded. Base64url is a URL-safe variant of base64 that uses - and _ instead of + and / and omits padding (=). Modern browsers' atob() function handles base64 but requires conversion: - → +, _ → /, add padding. If decoding fails, token is corrupted.
4. 4Step 4 — JSON Parsing: Decoded header and payload should be valid JSON objects. If JSON.parse fails, the token's contents are corrupted or this isn't a standard JWT. Some legacy systems use 'JWT-like' formats with binary or non-JSON content that won't decode here.
5. 5Step 5 — Claim Extraction and Analysis: Calculator extracts standard claims (exp, iat, nbf, sub, iss, aud) and displays them in human-readable form. exp and iat are converted from Unix timestamps to dates. Custom claims are shown in the full payload JSON for inspection.
6. 6Step 6 — Expiration Status Calculation: Current time (now) compared to exp claim. Status categories: VALID (exp > now + 7 days), EXPIRING SOON (exp > now but < 7 days), EXPIRED (exp < now, shows days ago), NOT YET VALID (nbf > now, token is for future use). Days remaining shown for context.
7. 7Step 7 — Signature Display (NOT Verified): The third segment (signature) is shown but never verified by this tool. Verification requires the secret (for HMAC algorithms) or public key (for asymmetric algorithms) and should be done server-side using a proper JWT library. Never trust unverified JWT contents in production code.

• !Confusing decode with verify — this tool only decodes; signature verification requires the cryptographic key and should be done server-side with a JWT library.
• !Trusting unverified JWT contents in security decisions — anyone can forge a valid-looking token; never authorize without verification.
• !Storing JWTs in localStorage with sensitive data — vulnerable to XSS attacks; use httpOnly secure cookies for production browser apps.
• !Forgetting to handle clock skew — allow 30-60 seconds tolerance on exp/nbf comparisons between distributed servers.
• !Using long-lived JWTs without rotation — once issued, JWTs cannot easily be revoked; use short-lived access + refresh token rotation pattern.