JWT Encoder / Decoder

A JSON Web Token (JWT) is a compact, URL-safe string used to represent claims between two parties. It consists of three base64url-encoded parts separated by dots: header.payload.signature.

The header declares the token type (typ) and the signing algorithm (alg), such as HS256 (HMAC-SHA256) or RS256 (RSA-SHA256). The payload contains the claims — statements about an entity (typically a user) and additional metadata. Common registered claims include iss (issuer), sub (subject), aud (audience), iat (issued at), and exp (expiration time).

The signature is computed by the issuer over the header and payload using a secret or private key. Decoding needs no key at all — the first two parts are only encoded, not encrypted, so treat everything in a payload as public. Never put a password, a card number or anything else sensitive in one unless the token is also encrypted (JWE).

Verifying a signature

Paste the key into the Verify Signature box in Decode mode and this tool checks the signature with your browser's built-in WebCrypto. For the HS family you need the shared secret; for RS and ES you need only the public key, which is the point of asymmetric signing — anyone can check a token, but only the holder of the private key can mint one.

A valid signature proves exactly one thing: the header and payload have not changed since they were signed by whoever holds that key. It does not mean the claims are true, that the issuer is who you expect, or that the token is still current. A verifier still has to check iss, aud and exp itself.

Why this tool refuses some tokens

You choose the algorithm; the tool will not read it out of the token and trust it. If the header says HS256 and you selected RS256, verification is refused rather than attempted. That mismatch is the algorithm-confusion attack: a server that trusts the header can be handed an HS256 token and will use its RSA public key as the HMAC secret — and a public key is, by definition, something the attacker already has, so they can forge any token they like.

For the same reason a token declaring alg: "none" can never verify here. It carries no signature at all, so its claims are unauthenticated input; libraries that honoured none were the source of a well-known family of authentication bypasses. Decode mode still shows you such a token — it just flags it rather than pretending a key would help.

Signing a token

Encode mode edits the header and payload as JSON and signs them. The algorithm you select is always what gets written into the header, so a token built here cannot claim to be signed one way while actually being signed another. HMAC secrets should be at least as long as the hash output — 32 bytes for HS256, 64 for HS512 (RFC 7518 §3.2) — because a short secret can be brute-forced offline from a single captured token. For RSA and ECDSA the tool can generate a fresh key pair for you, since browsers need PKCS#8 rather than the PKCS#1 format openssl genrsa produces.

Nothing you paste here leaves your browser: there is no server call, no analytics, and neither tokens nor keys are written to the URL or to storage. Clear keys wipes every key field at once. Related tools: Base64 Encoder / Decoder for the encoding JWTs are built on, and Hash Generator for the SHA-2 digests underneath every one of these algorithms.