JWT Structure Validator

JWT structure and what "valid" can mean

A JSON Web Token (JWT, RFC 7519) is three base64url-encoded segments joined by dots: header.payload.signature. The header declares the signing algorithm (alg) and the token type. The payload carries claims — standard ones like iss (issuer), sub (subject), aud (audience), exp (expiry), nbf (not-before), iat (issued-at) and jti (token ID) — plus any custom data the issuer wants. The signature is computed over base64url(header) + "." + base64url(payload) using the algorithm in the header.

This page checks the syntactic side only: three segments, valid base64url, JSON parses cleanly, claims have the expected types and the token is not expired. It does not verify the cryptographic signature — that requires the issuer's secret (for HMAC) or public key (for RSA/ECDSA), neither of which this tool has access to.

Signing algorithms

• HS256 / HS384 / HS512 — HMAC with SHA-2. Symmetric: same secret signs and verifies. Good for monoliths.
• RS256 / RS384 / RS512 — RSA-PKCS#1 v1.5 with SHA-2. Asymmetric: private key signs, public key verifies. The default for OAuth/OIDC.
• ES256 / ES384 — ECDSA over P-256 / P-384. Asymmetric, much shorter signatures than RSA.
• EdDSA — Ed25519 (or Ed448). Fast, modern, constant-time.
• PS256 / PS384 / PS512 — RSA-PSS, the recommended RSA padding scheme.

Common attacks and how to prevent them

The alg: none attack (CVE-2015-9235): a malicious token sets alg to none and ships no signature; libraries that blindly trust the header accept it. Fix: never let the token tell you which algorithm to use — pin an allowlist on the server.

The algorithm confusion attack: a token forged with HS256 using the issuer's RSA public key as the HMAC secret. If the server blindly calls verify(token, publicKey) without checking the algorithm, the forgery succeeds. Fix: the verification API must require the expected algorithm explicitly.

Other classics: expired-token replay if you ignore exp, audience confusion if you skip aud validation, key confusion via jku/x5u headers pointing at attacker-controlled URLs, and JWKS poisoning when an unprotected /.well-known/jwks.json endpoint serves attacker-injected keys.

Storage, payload size and best practices

Use short expiries — 15 minutes for access tokens, longer-lived refresh tokens stored separately. Keep tokens in HttpOnly, Secure, SameSite=Strict cookies, never in localStorage (any XSS vulnerability reads it instantly). Always validate iss and aud against your expected values. Rotate signing keys via JWKS and include a kid (key ID) in the header so verifiers can pick the right one.

Never put sensitive PII in a JWT payload — base64url is encoding, not encryption. If you need confidentiality, use JWE (encrypted) instead of plain JWS (signed). Recommended libraries: jose (Node, ESM-first, no historic CVEs), jsonwebtoken (Node, older, multiple historic CVEs around algorithm handling), PyJWT (Python), jjwt (Java).

FAQ

Can I decode a JWT without the secret? Yes — base64url decoding is trivial and reveals the header and payload in clear text. That is why you must never store passwords, credit card numbers or other PII inside. The secret is only needed to verify or forge the signature, not to read the contents.

How do I prevent the alg: none attack? Configure your verification library with an explicit algorithm allowlist. In jsonwebtoken for Node, that means jwt.verify(token, key, { algorithms: ['RS256'] }) — never omit that option.

Where should I store the refresh token? In an HttpOnly, Secure, SameSite=Strict cookie tied to a specific refresh endpoint. Never in JavaScript-readable storage, and never alongside the access token on the same path.

How big can a JWT get? No hard limit, but every request carries it in the Authorization header. Headers above 8 KB are commonly rejected by proxies and CDNs. Keep claims minimal; if you have a lot of state, store it server-side and put only an opaque ID in the JWT.