JWT Decoder

What a JWT is

A JSON Web Token is a compact way to carry signed claims between systems. The most common use is authentication: a server signs a token saying "this is user 4291, valid until 2pm tomorrow," hands it to the client, and accepts it back later as proof. Because the token is signed, the server doesn't need to remember it — it just verifies the signature and trusts the contents.

A JWT is three Base64URL-encoded segments separated by dots: header.payload.signature. The header and payload are JSON objects; the signature is a cryptographic hash of the first two parts plus a secret. This decoder splits any JWT you paste into its parts so you can inspect the claims, check the expiry, and confirm the algorithm used.

The three parts

Header

Tiny JSON object describing how the token is signed. Almost always looks like {"alg": "HS256", "typ": "JWT"}. The alg tells you which signature algorithm to use when verifying. Common values: HS256 (HMAC with SHA-256, symmetric secret), RS256 (RSA signature, public/private keypair), ES256 (ECDSA, smaller signatures, increasingly common).

Payload

The actual claims. Some are standardized:

• iss — issuer (who signed this)
• sub — subject (usually the user ID)
• aud — audience (who this token is for)
• exp — expiration (Unix timestamp, in seconds)
• iat — issued-at time
• nbf — not-before time
• jti — unique JWT ID, used for revocation

Anything else in the payload is application-specific: roles, permissions, email, tenant ID. There's no required schema beyond the standard claims.

Signature

The cryptographic seal. With HMAC, anyone with the secret can both create and verify tokens; with RSA or ECDSA, the issuer signs with a private key and verifiers use the corresponding public key. This decoder shows the signature but cannot verify it without the key — that's a server-side operation.

What's safe to put in a token

The payload is signed but not encrypted. Anyone who has the token can read everything in it — this decoder is proof of that. Don't put anything in a JWT that you wouldn't put in a URL or share with the bearer. User IDs, roles, and email addresses are typical; passwords, full credit card numbers, and anything sensitive belong elsewhere.

Common things to check when debugging a JWT

• Is it expired? Decode and compare exp against now. Most "the token doesn't work" problems are this.
• Is the audience right? Tokens issued for one service often won't validate at another. Mismatched aud claims are a frequent integration bug.
• Is the algorithm what you expect? If a verifier accepts whatever alg the token claims, an attacker can swap RS256 for HS256 and exploit the public key as the HMAC secret — a classic JWT vulnerability. The verifier should be configured to accept only specific algorithms.
• Is the issuer correct? If you trust tokens from one identity provider, check that iss matches before granting any access.

JWT vs. opaque session tokens

JWTs are stateless: the server reads the claims directly without a database lookup. That's their main appeal at scale. The downside is that you can't easily revoke a JWT before it expires — a leaked token is valid until exp, no matter what. Opaque session tokens (a random ID that points to a row in a sessions table) are slower and require the lookup but are revocable instantly. Pick based on which trade-off matters more for your system. Many production systems use both: short-lived JWTs (5–15 minutes) plus a refresh-token mechanism that hits the database.