JWT Decoder

What Is a JWT Token?

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. Pronounced “jot,” JWTs have become the de facto standard for authentication and authorization in modern web APIs and single-page applications. When you log into a web application and that application issues you a token to include in subsequent requests, there is a good chance that token is a JWT.

JWTs are self-contained: all the information the server needs to validate a request is encoded inside the token itself. This is why they are popular in stateless, distributed systems where checking a central session store on every request would be a bottleneck. The server encodes the user's identity and permissions into the token, signs it, and trusts future requests that carry a valid signature — no database lookup required.

JWT Structure: Header, Payload, Signature

Every JWT consists of three parts separated by dots: header.payload.signature. Each part is Base64URL-encoded, making the token URL-safe and embeddable in HTTP headers, query strings, and cookies.

Header. The header is a JSON object that describes the token itself. It typically contains two fields: alg (the signing algorithm, such as HS256, RS256, or ES256) and typ (always JWT). Some tokens include a kid (key ID) field to indicate which key was used for signing when multiple keys are in rotation.

Payload. The payload contains the claims — statements about the user or entity the token represents, plus any application-specific data. Claims are just key-value pairs. The JWT specification defines a set of registered (standard) claim names, but you can add any custom claims your application needs.

Signature. The signature is computed by taking the encoded header, a dot, the encoded payload, and signing the result with a secret (for HMAC algorithms) or a private key (for RSA/ECDSA). The signature guarantees that the token has not been tampered with. Changing any character in the header or payload invalidates the signature. This tool decodes and displays the signature but does not verify it — that requires the signing key.

Standard JWT Claims Explained

The JWT specification (RFC 7519) defines several standard claims that have well-known meanings across all JWT implementations:

exp (Expiration Time). A Unix timestamp (seconds since January 1, 1970) after which the token must not be accepted. This is the most important claim for security — short-lived tokens limit the window of opportunity for an attacker who captures a valid token. This tool shows the expiration date in human-readable UTC format and flags whether the token is expired or still valid.

iat (Issued At). The Unix timestamp when the token was created. Useful for determining token age and implementing “tokens issued before date X are invalid” revocation strategies.

nbf (Not Before). A Unix timestamp before which the token must not be accepted. Useful for scheduling tokens that should become valid in the future.

sub (Subject). The principal that is the subject of the JWT — typically a user ID or email address. Must be unique within the context of the issuer.

iss (Issuer). Identifies the principal that issued the JWT. Often a URL identifying the authorization server, such as https://auth.example.com.

aud (Audience). Identifies the recipients the JWT is intended for. The receiving service must verify that it is listed in the audience to prevent token reuse across different services.

jti (JWT ID). A unique identifier for the token. Used to prevent replay attacks by tracking which JTIs have already been processed.

JWT vs Session Tokens

Traditional web applications use session tokens: a random opaque string stored in a cookie, with the session data stored server-side in a database or cache. Every request requires a database lookup to find the session, validate it, and retrieve the user's data. This approach is simple and easy to revoke (just delete the session record).

JWTs shift the model: all user data is in the token, signed so the server can trust it without a database lookup. This scales better horizontally — any server can validate any JWT without shared session state. The tradeoff is revocation: once issued, a JWT is valid until it expires. If you need to invalidate a JWT (because the user logged out or their account was compromised), you need to implement a token blacklist, which reintroduces server-side state.

When NOT to Use JWT

JWTs are often overused. They are well-suited for stateless API authentication and cross-service authorization, but they are a poor fit for traditional web application sessions where you need immediate revocation, or for storing sensitive data (the payload is only encoded, not encrypted — anyone with the token can read it).

Never store sensitive information like passwords, SSNs, credit card numbers, or private keys in a JWT payload. The payload is visible to anyone who holds the token — this tool proves it. If you need to transmit sensitive data in a JWT, use a JWE (JSON Web Encryption) instead of a plain JWT (JWS).

For browser-based sessions, JWTs stored in localStorage are vulnerable to XSS attacks. Prefer HttpOnly cookies for session tokens, and use short expiration times combined with refresh tokens for JWTs.

How to Read JWT Tokens in Development

When debugging authentication issues, being able to quickly inspect a JWT is invaluable. Copy the token from your browser's DevTools (Network tab → request headers, look for Authorization: Bearer eyJ...), paste it into this tool, and instantly see the decoded claims without any server-side tools. You can verify the user ID, check whether the token is expired, confirm the correct roles or permissions are present, and inspect any custom claims your application adds.

This tool processes everything in your browser — the token is never sent to any server. It is safe to use with tokens from development and staging environments. For production tokens containing real user data, use local tooling like the jwt CLI or a trusted desktop application instead of any online tool.

Frequently Asked Questions

Is it safe to paste my JWT into this tool?

This tool decodes JWTs entirely in your browser using JavaScript — no data is ever sent to a server. However, as a best practice, avoid pasting production JWTs containing real user data into any online tool, including this one. For debugging production tokens, use the jwt decode CLI or a local development environment.

Why does my JWT start with eyJ?

The JWT header is always a JSON object like {"alg":"HS256","typ":"JWT"}. When this is Base64URL-encoded, it always starts with eyJ because eyJ is the Base64 encoding of {". All three parts of a JWT are Base64URL-encoded, which is why the header and payload always start with eyJ.

Can this tool verify the JWT signature?

No. Signature verification requires the secret key (for HMAC) or the public key (for RSA/ECDSA). This tool only decodes the header and payload, which are not protected by the signature. To verify a signature, use your application's JWT library with the correct key, or use a trusted tool that has access to the signing key.

My token has expired — what does that mean?

If the exp claim is in the past, the token is expired and should not be accepted by any correctly implemented server. Your application will typically respond with a 401 Unauthorized error. You need to refresh the token (if your app uses refresh tokens) or log in again to get a new valid token.

What is the difference between JWT and JWE?

A standard JWT (technically a JWS — JSON Web Signature) is signed but not encrypted. The payload is readable by anyone. A JWE (JSON Web Encryption) encrypts the payload so it can only be read by the intended recipient. JWEs start with a different structure and are much less commonly used than signed JWTs.

What algorithms are used to sign JWTs?

The most common signing algorithms are HS256 (HMAC-SHA256, symmetric — same secret for signing and verification), RS256 (RSA-SHA256, asymmetric — private key to sign, public key to verify), and ES256 (ECDSA with P-256, asymmetric, more compact signatures than RSA). The alg field in the decoded header tells you which algorithm was used.

How do I use the decoded payload in my application?

In JavaScript, you can decode a JWT payload with: JSON.parse(atob(token.split('.')[1].replace(/-/g, '+').replace(/_/g, '/'))). Most JWT libraries provide a decode() or verify() function that does this automatically. Always use verify() in production code — it validates the signature in addition to decoding the claims.