JWT Encoder and Verifier

How do I create a JWT?

Choose an algorithm, edit the header and payload JSON, enter a secret or private key, and click Encode and sign. The tool writes the header and payload as Base64URL, signs them with WebCrypto, and shows the three-part token. Use a test key, because anything you paste is handled by a web page.

This JWT encoder doubles as a JWT generator for testing and learning. The Add iat now and Add exp helpers insert the standard time claims as seconds since 1970, and the header alg field follows the selector. An HS256 JWT needs only a shared secret. RS256, PS256 and ES256 tokens need a private key as PKCS#8 PEM or a JWK. For RS, PS and ES algorithms, Load sample generates a fresh test key pair in your browser each time, so this page ships no private key. To read a token without any key, use the JWT decoder, and paste the finished payload into the JSON Formatter if you want to inspect or reshape it.

How do I verify a JWT signature?

Switch to the Verify tab, paste the token, pick the algorithm you expect, and enter the secret or public key. The tool recomputes the signature and reports valid or invalid with the reason. It checks with the algorithm you select, refuses a token whose header names another one, and shows the decoded header, payload and claims.

To verify a JWT signature online with RS256, paste the public key as SPKI PEM (BEGIN PUBLIC KEY) or as a public JWK. A private key pasted here is refused. If the header alg differs from your selection, the token is not verified, and a button offers to switch to the algorithm it names. A token whose alg is none, or whose signature is empty, is reported as NOT VERIFIED: unsigned token, never as valid. A valid signature shows only that the key matches. Whether the claims are acceptable is a separate question, so the claims panel shows exp, nbf and iat as dates and keeps them apart from the signature result. For the bigger picture, read how JWTs work in detail.

HS256 vs RS256 vs ES256: which should I use?

It depends on who must verify. HS256 uses one shared secret, so every verifier can also forge tokens. RS256 and ES256 use a key pair, so verifiers need only the public key, and ES256 signatures are far shorter. PS256 is a newer RSA variant. None is best in every case.

With HS256, the issuer and every verifier hold the same secret. That is simple and fast, but a leak in any one service lets an attacker mint tokens. With RS256 or PS256 only the issuer holds the private key; an RSA 2048 signature is 256 bytes, so tokens get longer. ES256 uses P-256 and a 64-byte signature, but not every library supports every curve, and a JWT carries the raw r and s values, not the DER format many tools print. The 384 and 512 variants change only the hash. They do not make a weak secret stronger.

Why does my JWT signature fail to verify?

The usual causes are a different secret or key, a different algorithm, a secret with a trailing newline, a Base64URL secret treated as plain text, or a token changed in transit. The tool names the likely cause and, for HMAC secrets, tells you when a trimmed or decoded secret would have verified.

Gotchas this tool checks for

• Base64URL is not Base64. JWT parts use - and _ with no = padding. The verifier rejects +, / and = with a message. To inspect a part by hand, use a Base64 decoder.
• UTF-8 payloads. Text is encoded as UTF-8 before signing, so emoji and accented letters round-trip. Bytes that are not valid UTF-8 are rejected.
• ES256 signatures are raw. A JWT signature is 64 bytes of r and s. A DER signature, usually 70 to 72 bytes, is reported as invalid with an explanation.
• PKCS#1 and SEC1 keys fail. BEGIN RSA PRIVATE KEY and BEGIN EC PRIVATE KEY cannot be imported by WebCrypto. Convert them to PKCS#8 first.
• A trailing newline is part of the secret. A secret copied from a file often ends with one. The tool warns, and tells you if the trimmed secret would have verified.
• Secret is Base64URL. Tick it only if the secret is stored encoded. After a failure the tool tries the opposite setting and reports which one matches.
• Clock skew. The claims panel compares exp, nbf and iat with this device's clock. A server a few minutes off may disagree, which is why many libraries allow some leeway.
• Large numbers. JavaScript rounds integers above 2⁵³ before signing, so the encoder warns; put such values in a string.

Is it safe to paste a JWT or secret here?

Your token and key never leave your browser, and nothing is written to storage or the address bar. A web page can still be compromised, and this site loads third-party scripts such as the Google tag. Use test keys here, and do not paste production secrets into any website, including this one.

Signing and verification run in your browser with WebCrypto, with no upload and no server round trip for your token or key. Analytics events record only the action, the algorithm family and the result, never the token, key or claims, and the fields are set not to autofill. Even so, treat a production secret as compromised once you have pasted it anywhere you do not control.

What does a signed and verified JWT look like?

This HS256 token was made by this tool with a published test key, then verified several ways. The results below come from the tool's own code, and the tokens were re-checked with Node's crypto module. Every key on this page is a test key: never use it for anything real.

Payload

{
  "iss": "https://example.test",
  "sub": "user-123",
  "name": "Ada Lovelace",
  "iat": 1700000000,
  "exp": 4102444800
}

Test secret, never use

jfh-test-secret-never-use-this-in-production-0123456789abcdefghij

HS256 token, split for display

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2V4YW1
wbGUudGVzdCIsInN1YiI6InVzZXItMTIzIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSI
sImlhdCI6MTcwMDAwMDAwMCwiZXhwIjo0MTAyNDQ0ODAwfQ.ZrQhGyxMEwcci5An
hXx0lE34UVBKvm_iDrg4aipB5dA

ES256 test public key, never use

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEO1FaTmepdzACVQUF7QX62nknFbpc
yIdosCkkr2G/brOYzI2VhL8fQfza0fmpW1gIud4jSRk+wXvbDolbkNQyXA==
-----END PUBLIC KEY-----

ES256 token

eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2V4YW1
wbGUudGVzdCIsInN1YiI6InVzZXItMTIzIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSI
sImlhdCI6MTcwMDAwMDAwMCwiZXhwIjo0MTAyNDQ0ODAwfQ.fnQoZwf0E-nqTyo2
27Fmk3krs1LQ_O6Y198fHF1XA3vfcjpQdGg3PxKl6kOVpftGc2ZrqpcIiV6P7fag
6jVtwA

What are the real risks with JWTs?

The main risks are trusting the alg in the token header, accepting the none algorithm, using a short or guessable HMAC secret, and treating a valid signature as proof that a token is acceptable. A JWT is also signed, not encrypted, so anyone who sees it can read its payload.

Algorithm confusion happens when a server lets the token choose the algorithm: an attacker signs an HS256 token with the server's RS256 public key as the HMAC secret. This verifier avoids it by using your selector, and by refusing a PEM key as an HMAC secret. The none algorithm makes unsigned tokens that a careless library may accept. A short HMAC secret can be brute-forced offline from a single token, so the tool warns below the hash size. Finally, check exp, nbf, audience and issuer in your own code, because a valid signature does not cover them.