JWT Builder & Verifier
Sign, decode and verify JSON Web Tokens with HS, RS, PS and ES algorithms — secrets and keys never leave your browser.
Settings
No clock skew · UTF-8 secret
How to Use JWT Builder & Verifier in 3 Steps
Build a token
Pick an algorithm, write the payload as JSON (click iat, exp, jti… to insert standard claims), and provide a secret for HS* or a PKCS#8 private key for RS*, PS* and ES*. No key yet? Generate key pair creates one in the browser and shows the matching public key. The token is signed live with Web Crypto.
Verify a token
Switch to Verify & decode and paste a token. Header and payload are decoded immediately, with exp / nbf / iat shown as readable dates and status badges. Add the HMAC secret, a PEM public key or a JWK / JWKS document to check the signature — the right key in a JWKS is picked by kid.
Copy or download
Copy puts the token (or decoded JSON) on the clipboard. Download the token, the decoded JSON, or the generated private / public key as PEM files.
JWT Builder & Verifier — Frequently Asked Questions
Are my secrets and keys safe here?
They never leave the tab: signing and verification use the browser’s built-in crypto.subtle, nothing is stored in localStorage, and nothing is sent to Toolity. Still, treat anything you paste into any web page as sensitive — rotate test secrets before production.
Which key formats are accepted?
Private keys as PKCS#8 PEM (BEGIN PRIVATE KEY), public keys as SPKI PEM (BEGIN PUBLIC KEY), and JWK or JWKS JSON. Legacy BEGIN RSA PRIVATE KEY / BEGIN EC PRIVATE KEY files are not understood by Web Crypto — convert with openssl pkcs8 -topk8 -nocrypt -in key.pem. X.509 certificates are not parsed.
What do “expired” and “not yet valid” mean?
exp is the moment after which a token must be rejected, nbf the moment before which it must not be accepted, and iat when it was issued — all Unix seconds. The badges compare them with your device clock plus the skew tolerance from Settings. A valid signature on an expired token is still shown as valid signature + expired, because those are separate checks.
Why is alg: none flagged?
A token with alg: none is unsigned; libraries that accept it have been the source of real breaches. The tool decodes it but marks it as unsafe, and it will never report a “valid signature” for it.
How do ES256 signatures compare with openssl output?
JWS uses the raw r || s form (64 bytes for P-256), which is also what Web Crypto produces, so tokens made here verify in jose, PyJWT, jsonwebtoken and friends. openssl prints DER-encoded signatures, which is a different wrapper around the same values.
Can I decode a token without the key?
Yes — header and payload are only base64url-encoded, not encrypted, so anyone can read them. Verification needs the key; without it the signature badge says “unverified”. Encrypted tokens (JWE, five segments) show their header only.