Free Web Security & Token Debugging Tool
JWT Decoder & Debugger
Decode, inspect, and analyze JSON Web Tokens (JWT) client-side in your browser. View formatted headers, claim payloads, signature verification algorithms, and live expiration countdowns without transmitting token data.
Header
Payload Claims
What is a JSON Web Token (JWT)?
A JSON Web Token (JWT)—formally standardized under IETF RFC 7519—is a compact, URL-safe means of representing claims to be transferred between two parties. JWTs are the industry-standard backbone of modern stateless authentication systems, OAuth 2.0 authorization frameworks, and OpenID Connect (OIDC) identity protocols.
Unlike legacy server-side session architectures (where an opaque session ID is stored in a database like Redis and looked up on every single HTTP request), a JWT is self-contained. The token carries all the necessary identity metadata, user permissions, and expiration timestamps directly inside its payload. Once verified cryptographically, the receiving server can trust the claims without querying a central session cache.
Signing vs. Encryption: The Core Distinction
A common misconception among web developers is assuming JWT tokens are encrypted. Standard JWTs are digitally signed (JWS), not encrypted. Anyone who intercepts a token can decode the Base64URL payload and read its contents. The signature ensures integrity and authenticity (proving the token has not been tampered with), not confidentiality. For sensitive payloads requiring encryption, the JWE (RFC 7516) standard is used.
The Three-Part Anatomy of a JSON Web Token
A compact JWT string consists of three distinct parts separated by periods (.):
Compact Token Representation
1. Header
Specifies the token type (usually JWT) and the cryptographic signing algorithm (such as HS256, RS256, or ES256).
{
"alg": "HS256",
"typ": "JWT"
}2. Payload (Claims)
Contains the statements about the user and additional entity metadata. Divided into registered, public, and private claims.
{
"sub": "user_987",
"name": "Jane Doe",
"exp": 1756700000
}3. Signature
Calculated by combining the encoded header, encoded payload, and a secret key or private key with the chosen hashing algorithm.
HMACSHA256( base64Url(header) + "." + base64Url(payload), secretKey )
Standard Registered Claims (RFC 7519 Reference)
RFC 7519 defines a set of official registered claim keys designed to provide a standard, interoperable metadata baseline for authentication systems:
| Claim Key | Full Name | Data Type | Description & Example |
|---|---|---|---|
| iss | Issuer | String (URI) | Identifies the principal that issued the JWT (e.g. "https://auth.company.com"). |
| sub | Subject | String | Identifies the subject of the JWT (e.g. user ID or entity "usr_4812a9"). |
| aud | Audience | String / Array | Identifies the recipients that the JWT is intended for (e.g. "https://api.company.com"). |
| exp | Expiration Time | Integer (Epoch) | Unix timestamp in seconds when the token becomes invalid. |
| nbf | Not Before | Integer (Epoch) | Identifies the time before which the JWT must not be accepted. |
| iat | Issued At | Integer (Epoch) | Unix timestamp indicating when the JWT was generated. |
| jti | JWT ID | String (UUID) | Unique token identifier used to prevent token replay attacks and manage revocation lists. |
Symmetric vs. Asymmetric Signing Algorithms
Selecting the appropriate cryptographic signature algorithm is a pivotal architectural decision when building distributed web applications:
| Algorithm Family | Common Ciphers | Key Architecture | Pros & Cons | Ideal Architectural Scenario |
|---|---|---|---|---|
| HMAC (Symmetric) | HS256, HS384, HS512 | Single shared secret string used for both signing and verifying. | ✓ Blazing fast ✗ Verifier can also forge tokens | Monolithic backends where the same server creates and consumes tokens. |
| RSA (Asymmetric) | RS256, RS384, RS512 | Private key signs; Public key (JWKS) verifies. | ✓ Verifiers cannot forge tokens ⚠ Larger token byte size | OAuth 2.0 / OIDC identity providers, multi-service microsystems. |
| ECDSA (Elliptic Curve) | ES256, ES384, ES512 | Elliptic Curve public/private key pairs. | ✓ Smaller key size & faster math ✓ Highly compact tokens | High-throughput mobile APIs, IoT devices, modern enterprise auth. |
Critical JWT Security Vulnerabilities & Prevention Checklist
Because JWTs are ubiquitous across modern web systems, security researchers continuously scrutinize implementation vulnerabilities. Implement these essential defenses:
1. Never Trust "alg: none" Unconditionally
The JWT specification allows an "unsigned" token mode designated by alg: none. Ensure your backend verification library explicitly enforces an algorithm whitelist (e.g., algorithms: ['RS256']) and rejects any token attempting to bypass cryptographic checks with "none".
2. Mitigate Algorithm Confusion Attacks
If your application expects RS256, an attacker might craft an HS256 token using your public RSA key (which is publicly visible) as the HMAC shared secret. Ensure your validation pipeline verifies that the algorithm family matches the exact key type provided.
3. Secure Storage: Avoid localStorage for Access Tokens
Storing authentication tokens in browser localStorage makes them easily accessible to any malicious JavaScript executed via Cross-Site Scripting (XSS). Store tokens in memory or in httpOnly; Secure; SameSite=Strict cookies to shield them from client-side script inspection.
4. Keep Access Token Lifespans Short (5 – 15 Minutes)
Because pure stateless JWTs cannot be easily revoked without maintaining a centralized blocklist, minimize the blast radius of a stolen token by enforcing short lifespans (5–15 minutes) paired with secure Refresh Token rotation.
Frequently Asked Questions About JSON Web Tokens
Expert answers regarding token decoding, cryptographic signing, expiration handling, and authentication architecture.