Create and sign JSON Web Tokens with HS256/384/512 for testing APIs — claim helpers for iat, exp, nbf and jti, secret encoding options, and warnings for common mistakes.
Loading JWT Generator…
Loading JWT Generator…
When I'm testing an API that expects a bearer token, I rarely want to stand up the real identity provider just to get one. A locally signed JWT with the right claims is enough — as long as it's signed exactly the way the API expects. This generator builds the token from a header and a payload you can edit as JSON, signs it with HMAC-SHA256, 384 or 512 using the browser's Web Crypto API, and colour-codes the three parts of the result. Buttons set iat to now, exp to a preset lifetime, nbf, and a random jti. It checks the things that make APIs reject test tokens: numeric dates in milliseconds instead of seconds, exp earlier than iat or already past, a missing exp, and secrets shorter than the algorithm requires. The secret can be interpreted as UTF-8 text, Base64 or Base64URL, which is the most common reason a token that "should" work fails verification. The output is checked in the test suite against tokens produced by the jsonwebtoken library, and "Open in decoder" hands the token — never the secret — to the JWT decoder through the URL fragment.
The header and payload are parsed (comments and trailing commas are tolerated), serialized as compact JSON, and Base64URL-encoded without padding. The header always starts with the selected alg and a typ of JWT unless you set one; other fields such as kid are kept.
The signing input is header.payload in ASCII. It is signed with HMAC using SHA-256, SHA-384 or SHA-512 via crypto.subtle, and the signature is Base64URL-encoded. The key bytes come from the secret as UTF-8, Base64 or Base64URL.
iat, exp and nbf must be numbers of seconds. The generator warns when one looks like milliseconds, when exp is before iat or in the past, when nbf is in the future, and when there is no exp at all.
Nothing is persisted or shared. "Open in decoder" puts only the token in the URL fragment, which browsers never send to a server, and the decoder removes it from the address bar after reading it.
Short answers for the things developers usually ask before trusting a tool.
No. Tokens are signed with your browser's Web Crypto API. The secret is kept only in the page's memory — it is never saved to storage, never included in a link, and not sent to a server. The page has no share button for that reason.
The most common cause is secret encoding: many frameworks treat the configured secret as Base64, others as plain text. The same characters give different key bytes, so the signature differs. Switch "Secret is" between Text and Base64 to match your server. Other causes are signing with the wrong algorithm and a secret with trailing whitespace.
At least 32 bytes (256 bits). RFC 7518 requires an HMAC key at least as long as the hash output, and libraries such as jose and .NET's Microsoft.IdentityModel reject shorter keys. The generator warns when the secret is too short for the chosen algorithm.
Seconds. JWT uses NumericDate: seconds since 1970-01-01T00:00:00Z. A 13-digit value is almost certainly milliseconds from Date.now(), and the generator warns about it.
Only after ticking an explicit checkbox, and with a warning. An unsigned token can be forged by anyone, so servers must reject it; it is useful only for testing that yours does.
Not yet — this version signs with HMAC (HS256, HS384, HS512). To inspect or verify RS256/ES256 tokens, use the JWT decoder, which verifies RSA and ECDSA signatures against a JWK.
Useful follow-ups when one conversion usually turns into three more.
Decode JWT header and payload locally so you can inspect claims and expiry quickly.
Generate HMAC-SHA1/256/384/512 in hex or Base64, and verify GitHub, Stripe, Slack and Shopify webhook signatures against the raw request body.
Convert text to Base64 and back with Unicode-safe browser-side processing.