← All tools

JWT Decoder & Security Analyzer

Decode any JSON Web Token, inspect its claims, and audit it against common security pitfalls — algorithm weaknesses, missing expiry, excessive lifetime, sensitive data in the payload. Everything runs in your browser; the token is never sent over the network.

Try:

100% client-side. Your token never leaves this page — decoding and analysis happen entirely in your browser.

What Is a JSON Web Token?

A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe way to transmit signed claims between two parties. The most common use is authentication: after a user signs in, the server hands back a JWT, the client stores it, and every subsequent request includes it in an Authorization: Bearer <token> header. The server verifies the signature, reads the claims, and trusts the identity inside without needing a session lookup.

A JWT is three base64url-encoded segments separated by dots: header.payload.signature. The header declares the signing algorithm. The payload contains the claims. The signature ties the two together with a secret (HMAC) or a private key (RSA, ECDSA, EdDSA).

Is a JWT Encrypted?

No. A JWT is signed, not encrypted. Anyone with the token can base64-decode the payload and read every claim. That includes attackers who intercept the token, log-aggregation systems that store requests, and front-end developers debugging in the browser DevTools.

Treat the payload as public-by-design. Never put passwords, API keys, personal financial data, or anything else you wouldn't print on a postcard. If you genuinely need to transport secrets in a token, use JWE (JSON Web Encryption) — the encrypted counterpart defined in RFC 7516.

What This Tool Checks

Algorithm weaknesses

The alg field in the JWT header decides how the signature is verified. A misconfigured server that accepts alg: none will trust any token, even one constructed by an attacker — the single most well-known JWT vulnerability. Symmetric algorithms (HS256, HS384, HS512) are also worth flagging, because servers that accept multiple algorithm types are vulnerable to algorithm confusion attacks where an attacker uses the RSA public key as an HMAC secret. This tool surfaces both classes.

Expiration and lifetime

A token without an exp claim never expires from the verifier's perspective. If compromised, the attacker has indefinite access. We flag missing exp, expired tokens, tokens issued in the future (a sign of clock skew or tampering), and excessively long lifetimes. Industry norms: access tokens minutes to hours, refresh tokens days to weeks. A 10-year access token is a finding, not a feature.

Sensitive data in the payload

Because JWT payloads are base64-encoded (not encrypted), placing secrets in claims is a common mistake. We scan claim names for patterns like password, secret, apiKey, privateKey, creditCard, and other red-flag keys. If you legitimately need this data in transit, use JWE or transmit it through a different channel.

Standard claims breakdown

The seven registered claims defined in RFC 7519 — iss, sub, aud, exp, nbf, iat, jti — get their own panel with human-readable times and explanations. Custom claims appear in the raw payload above.

Frequently Asked Questions

Is my token safe to paste here?

Yes. Decoding and analysis happen entirely client-side; the token never crosses the network. You can verify this by opening your browser's DevTools Network tab while pressing Decode — no requests are made. The analysis engine is open source at src/lib/jwt-decoder.ts in the repository if you'd like to read it.

Why does the tool say my valid token is "expired"?

Tokens carry an exp claim with the expiration timestamp. If the current time is past that timestamp, the token is expired and a correctly configured server will reject it. The token still decodes correctly — expiration is a runtime check, not a structural issue.

Should I use HS256 or RS256?

For systems where the signer and verifier are the same service, HS256 with a strong shared secret is fine and faster. For distributed systems where multiple services verify tokens issued by one authority, RS256 or ES256 is preferable — verifiers only need the public key, so leaking a single service's key doesn't compromise the rest of the system. Always configure your library to accept exactly one algorithm; never allow the token to dictate which.

What's the difference between JWT and a session cookie?

A session cookie is an opaque identifier that points to server-side state — the server looks up the session in a database on every request. A JWT carries the claims themselves, signed; the server trusts the signature and reads the claims without a lookup. JWTs scale better for stateless APIs; sessions are easier to revoke. Many production systems use both: short-lived JWTs for API access, server-side state for refresh and revocation.

How do I revoke a JWT before it expires?

You can't, directly — that's the trade-off for statelessness. The common patterns are: keep tokens short-lived (minutes) and rely on refresh-token rotation; maintain a server-side denylist of revoked jti values; or version the signing key and rotate to invalidate all outstanding tokens at once. Pick based on your security and operational requirements.

What does alg: none mean and why is it dangerous?

The JWT spec includes a "none" algorithm meaning the token is explicitly unsigned. Some early JWT libraries accepted such tokens by default — meaning an attacker could craft any payload, set the algorithm to none, and have it trusted. Modern libraries reject this by default, but the vulnerability still appears in misconfigured services. This tool flags it as a critical finding.

Further Reading