Free Online JWT Decoder, Inspector & Verifier

1. The Anatomy of a JSON Web Token (RFC 7519)

A standard signed JSON Web Token (JWS) consists of three base64url-encoded parts separated by period (.) delimiters: Header, Payload, and Signature. Each segment serves a dedicated cryptographic and identity role.

• Header (Red/Rose): Defines the token type (usually 'JWT') and the signing algorithm ('alg', e.g. HS256, RS256, ES256).
• Payload (Violet/Purple): Contains the claims—statements about the user, permissions, issuer, and token lifecycle.
• Signature (Cyan/Teal): Generated by hashing the encoded Header and Payload with a secret or private key to ensure tamper-proof integrity.

// Standard JWT Structure:
header.payload.signature

// 1. Decoded Header:
{ "alg": "HS256", "typ": "JWT" }

// 2. Decoded Payload:
{ "sub": "usr_10293", "name": "Jane Doe", "role": "admin", "exp": 1757000000 }

// 3. Signature Calculation (HMAC SHA-256):
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

2. RFC 7519 Standard Registered Claims Reference

The IETF RFC 7519 specification defines a set of registered standard claims that provide uniform metadata across modern authentication and API ecosystems.

• iss (Issuer): Identifies the authority that created the token (e.g. https://auth0.com or https://accounts.google.com).
• sub (Subject): The unique identifier for the user or entity the token represents (e.g. user ID or service UUID).
• aud (Audience): The intended recipients or backend APIs that should accept this token.
• exp (Expiration Time): Unix epoch timestamp marking when the token must no longer be accepted by APIs.
• nbf (Not Before): Unix epoch timestamp specifying the earliest time at which the token becomes active.
• iat (Issued At): Unix epoch timestamp indicating exactly when the token was signed and issued.
• jti (JWT ID): A unique cryptographic identifier for the token, useful for blacklisting and preventing replay attacks.

3. Timestamp Intelligence & Expiration Auditing

Expired tokens are the #1 cause of sudden 401 Unauthorized errors in frontend applications and microservices. Our Timestamp Intelligence engine automatically evaluates exp, iat, and nbf against your current local clock.

• Converts raw Unix epoch integers into local system time, UTC string, and ISO 8601 formatting.
• Calculates human-readable relative time (e.g. 'Expires in 2 hours 15 mins' or 'Expired 3 days ago').
• Displays live visual health status badges: Valid & Active, Token Expired, Not Yet Valid, or Missing Expiration.

4. Client-Side Cryptographic Signature Verification

Unlike server-dependent tools that require uploading your private signing secrets to a remote backend, Try & Tool leverages the browser's native Web Crypto API (SubtleCrypto) to verify signatures completely inside your browser sandbox.

• HMAC Symmetric Verification: Test HS256, HS384, and HS512 tokens with raw text secrets or Base64-encoded binary keys.
• RSA / ECDSA Asymmetric Verification: Test RS256, RS384, RS512, ES256, and ES384 signatures using standard X.509 / SPKI PEM public keys.
• Real-time validation feedback confirms whether the signature matches or if the token has been tampered with.

5. Critical Security Vulnerabilities in JWT Implementations

Understanding common JWT architectural pitfalls helps development teams build secure authentication systems and protect user credentials.

• The 'alg: none' Exploit: If an API server fails to enforce expected algorithms, attackers can alter the payload and set 'alg' to 'none' to bypass authentication entirely.
• Weak HMAC Secrets: Using short or dictionary-based HMAC secrets allows attackers to crack signatures offline via brute-force dictionary tools.
• Storing Sensitive Data in Payloads: Because standard JWT payloads are merely Base64Url-encoded and unencrypted, storing passwords, API tokens, or PII leaks data to anyone who intercepts the token.