About JWT Playground

Build or take apart a JWT and see exactly which checks a verifier would fail it on. Part of the DevTools Surf developer suite. Browse more tools in the Security / Crypto collection.

Use Cases

• Learn JWT structure by encoding and decoding tokens with different claims and algorithms.
• Test token expiry logic by crafting JWTs with specific exp values and verifying rejection behavior.
• Debug authentication issues by generating a valid token with known claims to test API endpoints.
• Compare token sizes across different algorithms and payload sizes for bandwidth planning.

Tips

• Use the playground to understand the three-part structure (header.payload.signature) before implementing JWT in production code.
• Test both HS256 (symmetric, shared secret) and RS256 (asymmetric, public/private key) to understand the tradeoffs — RS256 allows public verification without sharing the signing key.
• Always verify the 'alg' header in your application code — the 'none' algorithm bypass and algorithm confusion attacks exploit libraries that trust the token's declared algorithm.

Fun Facts

• The JWT 'none' algorithm attack was discovered in 2015 by Tim McLean. He found that multiple JWT libraries accepted tokens with 'alg: none' and no signature — treating unsigned tokens as valid.
• Auth0's 2021 analysis found that RS256 JWTs in production are typically 2-3x larger than HS256 tokens because the RSA signature (256-512 bytes) is far larger than an HMAC-SHA256 output (32 bytes).
• JWTs were designed to be stateless — the server needs no database lookup to verify a token. This is the main advantage over opaque session tokens, which require a session store lookup per request.

FAQ

Does it verify signatures?

Yes — enter the secret (HS256) or public key (RS256/ES256) and the playground verifies the signature, highlighting whether the token is valid, expired, or has been tampered with.

Can I generate RSA or EC key pairs for RS256/ES256?

Use the Key Pair Generator tool to generate a 2048-bit RSA or P-256 EC key pair, then paste the private key here to sign tokens and the public key to verify them.

What claims should every JWT include?

iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued at), and jti (unique token ID for replay prevention). All but sub and iss are technically optional but recommended.