Are my token, secret or keys sent to a server?

No. Decoding, verifying, signing and key generation all run locally in your browser using the built-in Web Crypto API. Tokens, secrets and private keys are never uploaded, logged or stored anywhere.

Can this verify a JWT signature?

Yes. It verifies HS256/384/512 with a shared secret (UTF-8 or base64/base64url), RS256/384/512 and PS256/384/512 with an RSA public key, ES256/384/512 with an EC public key, and EdDSA (Ed25519) where the browser supports it. Keys can be a PEM public key, an X.509 certificate PEM, a JWK, or a JWKS where the key is picked by the token's kid. Tokens with alg none are always rejected.

Can I create and sign a JWT here?

Yes. Edit the header and payload JSON, add standard claims like iat, exp, nbf, iss, aud, sub and jti with one click, pick an algorithm and sign with a secret, a PKCS#8 private key PEM or a private JWK. The Keys tab generates fresh HMAC secrets and RSA, EC and Ed25519 key pairs to sign with.

Usually not. A standard signed JWT is only Base64URL-encoded, so anyone can read its contents. The signature proves it wasn't altered, but it does not hide the payload. Never store secrets in a JWT payload.

What is the kid and the JWK thumbprint?

The kid (key ID) header tells a verifier which key in a JWKS signed the token. This tool sets it to the RFC 7638 JWK thumbprint: a SHA-256 hash of the key's required public members, so the ID is stable and derived from the key itself. The JWKS builder assembles public keys into a {"keys": [...]} document to serve at /.well-known/jwks.json.

JWT Decoder, Verifier & Generator — Decode, Verify & Sign JWTs · Free & Private

Decode a JSON Web Token, verify its signature with a secret, PEM, JWK or JWKS, sign new tokens and generate keys — all in your browser.

How to decode, verify and sign a JWT

Paste a token into Decode & Verify. The header and payload decode instantly, and exp, nbf and iat are shown with relative times.
Paste the shared secret (HS256/384/512) or the public key — PEM, certificate, JWK or a whole JWKS — into the verify box. The result turns into a clear ✓ verified or ✗ invalid.
To create a token, open Sign, edit the header and payload JSON, add claims with one click and paste a secret or private key.
No key yet? The Keys tab generates HMAC secrets and RSA, EC or Ed25519 key pairs as PEM and JWK.

What is a JWT?

A JSON Web Token is a compact, URL-safe way to represent claims between two parties. It has three parts separated by dots: a header (algorithm and type), a payload (the claims), and a signature. The first two are just Base64URL-encoded JSON, so anyone can read them. The signature is computed over header.payload with a secret or private key, and it is the only thing that makes a token trustworthy: change a single character of the payload and verification fails.

Decoding vs. verifying

Decoding reveals the contents; verifying proves the token was issued by whoever holds the key and has not been modified. This page verifies with the browser's built-in Web Crypto API: HMAC for HS*, RSASSA-PKCS1-v1_5 for RS*, RSA-PSS (salt length equal to the hash size) for PS*, ECDSA with raw r‖s signatures for ES*, and Ed25519 for EdDSA in browsers that support it. With a JWKS, the key is picked by the token's kid. It is ideal for debugging a failing integration or checking a key rotation. In production, your server must still verify every token itself before trusting its claims — a check in your browser tells you the token is good, it does not protect your API.

Algorithm confusion and alg "none"

The header's alg is chosen by whoever made the token, so a verifier must never let it decide how to check the signature. Two classic attacks exploit that. With alg "none", an attacker strips the signature and declares the token unsigned; libraries that honoured it accepted forged tokens. With algorithm confusion, a token meant for RS256 is re-signed as HS256 using the server's public key as the HMAC secret — if the server passes its RSA public key to a generic verify function, the forgery checks out, because that public key is, well, public.

The defence is to pin the algorithm to the key: an RSA key only verifies RS/PS tokens, an EC P-256 key only ES256, a shared secret only HS*. This tool follows that rule — it always rejects alg: none, refuses to treat a PEM or RSA/EC JWK as an HMAC secret, rejects a key whose type or curve doesn't match the header, and rejects a JWK pinned to a different alg. Configure your server library with an explicit allow-list of algorithms for the same reason.

Signing tokens and generating keys

The Sign tab builds a token from JSON you control. Quick-add buttons insert iat (now), exp (+1 hour or +1 day), nbf, iss, aud, sub and a random jti. HMAC tokens sign with a secret; the other algorithms take a PKCS#8 private key PEM or a private JWK. The Keys tab generates a random HMAC secret (base64url), a 2048/3072/4096-bit RSA key, an EC key on P-256, P-384 or P-521, or an Ed25519 key, and shows the private key (PKCS#8) and public key (SPKI) as PEM plus both as JWK. The kid is the RFC 7638 thumbprint of the public key, and the JWKS builder collects public keys into the document your identity provider or API serves. Keys are generated by your browser's cryptographically secure generator and never leave the tab — but treat a key you plan to use in production like any other secret and move it straight into your secret manager.

Common claims

iss issuer, sub subject, aud audience, exp expiry time, iat issued-at, nbf not-before and jti a unique token ID. Time claims are Unix timestamps in seconds; this tool shows exp, nbf and iat as readable dates with relative times and flags a token that has expired or isn't valid yet — even when its signature is fine.

Are my token and keys safe here?

Yes. Tokens, secrets and private keys are sensitive, so this tool never sends them anywhere. Decoding, verification, signing and key generation all happen in your browser tab — you can confirm in the network tab, and it works offline once the page has loaded.

JWT · Decode, Verify & Sign

JWKS builder