JWT Decoder

JSON Web Tokens (JWTs) have become the dominant standard for stateless authentication in modern web applications. They appear in OAuth 2.0 flows, single sign-on systems, API authorization headers, and session management. Yet despite their ubiquity, JWTs are frequently misunderstood, leading to security vulnerabilities, performance issues, and implementation mistakes that can compromise an entire application.

The Three Segments of a JWT

A JWT consists of three Base64URL-encoded segments separated by dots: header.payload.signature. Each segment serves a distinct purpose.

The header specifies the signing algorithm (like HS256, RS256, or ES256) and the token type. This is metadata about how the token was created, not the content itself. The header is not secret — anyone who possesses the token can read it.

The payload contains the claims — structured data about the subject (user), issuer, audience, expiration time, and any custom data your application needs. Standard claims include sub (subject/user ID), iss (issuer), aud (audience), exp (expiration timestamp), and iat (issued-at timestamp). Like the header, the payload is not encrypted — it is simply encoded.

The signature is the security mechanism. It is created by taking the encoded header and payload, and hashing them with a secret key (for HMAC algorithms like HS256) or signing them with a private key (for asymmetric algorithms like RS256). The signature allows anyone with the corresponding verification key (shared secret for HMAC, public key for RSA) to verify that the token was created by the expected issuer and has not been modified.

Security Properties and Limitations

JWTs provide three security properties when implemented correctly. Integrity: the signature ensures the token has not been tampered with. Authenticity: only someone with the signing key could have created a valid signature. Non-repudiation: the issuer cannot deny having issued the token (for asymmetric algorithms).

However, JWTs have important limitations. They are not encrypted — the payload is readable by anyone who possesses the token. Never put sensitive data (passwords, social security numbers, credit card numbers) in a JWT payload unless you are using JWE (JSON Web Encryption), which is a separate specification.

JWTs also cannot be revoked before their expiration time without additional infrastructure. Once issued, a valid JWT will remain valid until exp is reached. This is why short expiration times (5–15 minutes for access tokens) and refresh token rotation are essential for security.

Common Implementation Mistakes

Accepting the algorithm from the header is the most dangerous JWT vulnerability. If your server reads the algorithm from the token's header instead of expecting a fixed algorithm, an attacker can change the algorithm to "none" (which some libraries accept) or switch from RS256 (asymmetric) to HS256 (symmetric) and use the public key as the HMAC secret. Always specify and validate the expected algorithm on the server side.

Long expiration times reduce security. Access tokens should expire within 5–15 minutes. If a token is stolen, a short expiration limits the window of misuse. Use refresh tokens with rotation to obtain new access tokens without requiring the user to re-authenticate.

Missing issuer and audience validation allows token confusion attacks. Always verify that the iss claim matches your expected issuer and the aud claim matches your API. Without these checks, a token issued for one service could be accepted by another.

When to Use JWTs vs. Sessions

JWTs excel in stateless architectures where the server does not store session state — microservices, serverless functions, and distributed systems. They are also ideal for cross-domain authentication (SSO) because the token is self-contained and does not require a shared session store.

Server-side sessions are simpler for traditional web applications where all requests go to the same server. They allow instant revocation, do not require a token format specification, and avoid the complexity of token refresh flows. For most standard web applications, server-side sessions remain a perfectly valid choice.

Using This Decoder

Paste any JWT token to decode its header and payload. The decoder shows the expiration status with a live countdown, highlights standard claims, and provides beautified JSON output. This tool decodes only — it does not verify signatures. For signature verification, you need the signing secret or public key, which should be verified on your server.