JWT Encoder

What this tool is used for

• Producing a token with specific claims to reproduce a bug that only appears for one kind of subject.
• Building a fixture whose expiry is already in the past, to test that rejection actually happens.
• Checking that your service accepts the exact claim set an identity provider will send.
• Signing a short-lived token for a local integration test without standing up an auth server.
• Comparing your encoder's output against a reference to find a canonicalisation difference.

Frequently Asked Questions

Is a JWT encrypted?

No — the header and payload are Base64URL-ENCODED, not encrypted, so anyone holding the token can read every claim. The signature proves integrity and origin, nothing more. Never put a secret in a JWT payload.

What is the alg:none vulnerability?

A real historical attack: a token specifying alg:none with no signature was accepted by naive libraries, letting anyone forge any claim. Always validate against an EXPECTED algorithm rather than trusting the header's.

When should I use RS256 rather than HS256?

When more than one party verifies. HS256 is symmetric, so every verifier can also SIGN — meaning any service that checks tokens can mint them. RS256 lets you distribute a public key that only verifies.

Which claims should I always set?

exp (expiry) above all — a token without it is valid forever. Then iss and aud so a token minted for one service is not accepted by another, and iat for auditing. Keep exp short and use refresh tokens.

Can a JWT be revoked?

Not inherently, and this is its main weakness. Verification is stateless, so a stolen token stays valid until it expires. Revocation requires a denylist or short expiry with refresh — which gives back the server state JWTs were meant to avoid.

What is the kid header for?

It names which key to verify with, so a service can rotate keys without breaking tokens still in flight. It is also an injection point — a server that fetches a key from a path built out of `kid` can be pointed at a key the attacker controls.

Where should a token be stored in a browser?

Neither option is free. localStorage is readable by any script that gets injected; a cookie is sent automatically and needs CSRF protection. An httpOnly, SameSite cookie is usually the better trade, since it removes the XSS exfiltration path.

Common errors and gotchas

• Putting anything secret in the payload. It is signed, not encrypted, and anyone holding the token can read it.
• Accepting the algorithm from the token's own header, which is how `alg: none` and key-confusion attacks work.
• Omitting an expiry, which turns a leaked token into a permanent credential.
• Using a short or guessable HMAC secret, where the signature adds no protection at all.
• Assuming revocation is possible. A stateless token stays valid until it expires unless you add a denylist.