Is it safe to generate production JWTs with this tool?
No — don't use online-generated tokens in production. Generate real signing keys and tokens on your own backend; use this tool for testing, local development, and learning.
JWT Generator
Configuration
Generated JWT
The generated token and its segments will appear here.
Algorithm reference
| Algorithm | Family | Key type | Typical key size | Signature size | Who can verify |
|---|---|---|---|---|---|
| HS256 | HMAC-SHA256 | Symmetric (shared secret) | ≥256-bit secret recommended | 32 bytes | Anyone holding the secret — and anyone who can verify can also forge |
| HS384 | HMAC-SHA384 | Symmetric | ≥384-bit secret | 48 bytes | same |
| HS512 | HMAC-SHA512 | Symmetric | ≥512-bit secret | 64 bytes | same |
| RS256 | RSASSA-PKCS1-v1_5 + SHA-256 | Asymmetric RSA | 2048-bit+ recommended | matches key size (256 bytes at 2048-bit) | Anyone with the public key; cannot forge without the private key |
| RS384 | RSASSA-PKCS1-v1_5 + SHA-384 | RSA | 2048-bit+ | 384 bytes at 3072-bit key | same |
| RS512 | RSASSA-PKCS1-v1_5 + SHA-512 | RSA | 2048-bit+ | 512 bytes at 4096-bit key | same |
| ES256 | ECDSA P-256 + SHA-256 | Asymmetric EC | 256-bit curve | 64 bytes | Public key only; much smaller keys/signatures than RSA at equivalent strength |
| ES384 | ECDSA P-384 + SHA-384 | EC | 384-bit curve | 96 bytes | same |
| ES512 | ECDSA P-521 + SHA-512 | EC | 521-bit curve | 132 bytes | same |
HS* — single issuer that is also the only verifier (internal services sharing one secret over a secure channel). Simplest and fastest, but the secret must never reach an untrusted verifier — anyone who can check a signature with it can also mint new tokens with it.
RS* — multi-party verification, e.g. an OIDC identity provider signing tokens that many independent relying parties verify via a published JWKS endpoint. The private key never leaves the issuer; verifiers only ever see the public key and can't forge tokens with it.
ES* — same asymmetric trust model as RS*, but with much smaller keys and signatures at equivalent security (a 256-bit EC key ≈ a 3072-bit RSA key in strength). Increasingly the default choice for new OIDC deployments; needs EC library/runtime support.
Common vulnerabilities
The "none" algorithm
The JWT/JWS spec (RFC 7519 / RFC 7515) defines "alg": "none" as a valid, deliberately-unsigned token for cases where integrity isn't required. If a verifying library reads the alg value out of the untrusted token itself to decide how to verify it, an attacker can strip the signature entirely, rewrite the header to {"alg":"none"}, and the library will accept the token with no signature check at all — full claim forgery (change sub, escalate role, etc.).
The fix, in one sentence: the verifier must pin the algorithm(s) it expects out-of-band, and never let the token's own header select the verification method.
Key confusion (RS256 → HS256 downgrade)
Happens when a server is configured to verify "whatever algorithm the token claims" and reuses one piece of key material across both HMAC and RSA verification code paths. An RSA public key is, by definition, public — often published at a JWKS endpoint. An attacker who knows it can:
- Craft a token with
"alg": "HS256"instead of the server's realRS256. - Sign it with HMAC-SHA256, using the RSA public key's PEM/DER bytes as the HMAC secret.
- If the verifying code fetches "the key for this issuer" generically and calls an HMAC-verify function without checking that the key material is actually a symmetric secret (not a public key), the forged signature validates — the public key string has been repurposed as a shared secret.
The fix, in one sentence: never let the token select its own algorithm or key type; the verifier must pin both per issuer/audience, server-side.
About this JWT Generator
Create signed JSON Web Tokens locally — HMAC, RSA, or ECDSA at 256/384/512 bit — for testing and development.
Tokens are signed locally using the Web Crypto API: HS256/384/512 with a plain secret, RS256/384/512 and ES256/384/512 with a PKCS#8 private key in PEM form. The key and payload are never sent anywhere.
FAQ
Which signing algorithms are supported?
Nine, across three families: HMAC (HS256/384/512) with a plain secret, RSA (RS256/384/512) with a PKCS#8 private key in PEM form, and ECDSA (ES256/384/512) with a PKCS#8 EC private key in PEM form.
Does my signing secret leave my browser?
No — signing happens entirely client-side. A signing secret pasted into a server-side tool should be considered compromised the moment you paste it; that's exactly the risk this avoids.
What claims should every JWT include?
At minimum, set exp so the token expires. Common others: sub (subject/user ID), iss (issuer), aud (audience), iat (issued at).
Can I generate an unsigned token (alg: none)?
No — every token here requires a signing key; there's no alg: none escape hatch. That's intentional: unsigned tokens are a well-known JWT vulnerability class, so this tool won't produce one.
Can I check the token I just generated?
Yes — paste it into the JWT Decoder to inspect the header, payload, and claims, or verify the signature against the same key.
Related tools