JWT Encoder & Verifier

Sign builds a JWT from the header JSON, the payload JSON and a key. The header starts as {"alg":"<your algorithm>","typ":"JWT"} and you may edit it, but its alg must match the selected algorithm. If it does not, you get an error and nothing is rewritten for you. Both texts are encoded exactly as you typed them, including spaces and number formatting. The one exception is line breaks: browsers give a text box line breaks as LF, so they are always encoded as LF.

Verify checks a compact JWT against the key and the algorithm you selected. The header and payload are shown only after the signature has been verified, so you are never nudged to trust content that was not checked. To inspect a token without verifying it, use the JWT Decoder.

Verification does not check claims. A token with a valid signature can still be expired (exp), not yet valid (nbf) or meant for someone else (aud). Those checks belong to the application that receives the token.

Supported: HS256, HS384, HS512 (HMAC), RS256, RS384, RS512 (RSA PKCS#1 v1.5), PS256, PS384, PS512 (RSA-PSS with a salt as long as the hash output, as JWA requires) and ES256, ES384, ES512 (ECDSA on P-256, P-384 and P-521, with the raw r||s signature that JWS uses). EdDSA, JWE and JWKS are not supported. "none" is never accepted.

Keys: a UTF-8 secret or a JWK for HMAC; a PKCS#8 PEM (BEGIN PRIVATE KEY), an SPKI PEM (BEGIN PUBLIC KEY) or a JWK for RSA and EC. To verify you can also paste a private key, and its public half is used. PKCS#1 (BEGIN RSA PRIVATE KEY), SEC1 (BEGIN EC PRIVATE KEY), encrypted keys and certificates are not supported and are rejected; convert them to PKCS#8 first.

An HMAC secret must be at least as long as the hash output, measured in UTF-8 bytes: 32 bytes for HS256, 48 for HS384 and 64 for HS512 (RFC 7518 section 3.2). Shorter secrets are rejected, when signing and when verifying; there is no compatibility mode. A secret in a language such as Thai or in emoji counts by its bytes, not its characters. For a JWK oct key the decoded key bytes count. RSA keys must be 2048 to 8192 bits.

The key must fit the algorithm. A public key or a JWK can never be used as an HMAC secret, an RSA key is not accepted for ES algorithms, and an EC key must use the curve of the algorithm (P-256 for ES256, P-384 for ES384, P-521 for ES512).

A token must be exactly three base64url parts separated by dots, with no padding, spaces, line breaks or prefix such as "Bearer ". The header and payload must be valid UTF-8 JSON objects: a byte order mark, duplicate keys and invalid UTF-8 are rejected, and a payload that is not an object is rejected. A header with a crit parameter is rejected, because its required extensions are not understood. The header fields kid, jku, jwk and x5u are ignored: no key is ever fetched or taken from the token.

The signature length is checked before any cryptography runs, so truncated, extended or DER-encoded ECDSA signatures are rejected. Errors never include your key, secret or token; they use fixed messages.

Keys and secrets stay in this browser tab and are never sent or stored by DevTrove. They are still visible to browser extensions and to anyone using this device. Use test keys, not production secrets or private keys. Nothing is saved, put in the page address or sent to a server, and secrets and private keys are hidden by default.

Limits: header, payload and token up to 1,000,000 characters, a PEM or JWK up to 16 KiB, a secret up to 4,096 characters. Signing and verifying take milliseconds and use the browser's built-in Web Crypto, which is available on HTTPS pages and localhost. Only Chromium-based browsers have been checked; Firefox and Safari are not verified.