Build and sign a JWT with HS256, HS384, HS512, or RS256, using a test key that never leaves your browser.
Start here Pick the algorithm your verifier is configured to accept.
Header
Signed bytes (header.payload)
The signature covers exactly the bytes above. Change one character of either segment and verification fails.
Open this token in the JWT DecoderUnderstand the format
Signing a JWT is three steps: Base64URL the header, Base64URL the claims, then sign those exact bytes with a key the verifier already trusts.
A signed JWT is header.payload.signature, and the signature is computed over the ASCII string formed by the first two segments joined with a dot. Nothing else is included: not the whitespace of your original JSON, not the order you typed the claims in, only the encoded bytes. That is why this page shows the signing input alongside the token, because it is the value your verifier will reconstruct and check.
It also explains a common confusion. Re-encoding the same claims with different key order or spacing produces a different signing input and therefore a completely different signature, even though the decoded claims are identical. A JWT is not canonical; it is a specific byte sequence with a signature attached.
HS256, HS384, and HS512 are HMAC with a shared secret: the same value both signs and verifies. That is fine when one service does both, and a poor fit when many services must validate tokens, because every verifier would also be able to mint them. The secret should be long random bytes, not a memorable phrase; HS256 uses a SHA-256 HMAC, so at least 256 bits of key material is the sensible target.
RS256 signs with an RSA private key and verifies with the matching public key, usually published as a JWKS document. Verifiers then need no secret at all, which is what makes it the default for identity providers. This page accepts an unencrypted PKCS#8 private key; if your file begins with BEGIN RSA PRIVATE KEY it is PKCS#1 and needs converting first with openssl pkcs8 -topk8 -nocrypt.
Historically, libraries chose the verification algorithm by reading the alg header of the token being checked. An attacker could set alg to none and strip the signature, or change RS256 to HS256 and sign with the public key as if it were an HMAC secret, since that key is published. Both produce tokens that vulnerable verifiers accept.
The fix belongs on the verifying side: configure the expected algorithm and reject anything else, rather than trusting the header. RFC 8725 collects this and the rest of the current best practice. When you generate a test token here, changing the algorithm changes the header, which makes it a useful way to check that your verifier rejects what it should.
A realistic test token needs the claims your verifier checks, not just a subject. Set iss and aud to match the service configuration, exp to a near-future time, and iat to now. Tokens that omit exp never expire, which is convenient in a fixture and dangerous if one escapes into a shared environment.
Keep the payload small and public. Claims are only encoded, never encrypted, so anyone holding the token can read them; a JWT is the wrong place for anything the bearer should not see.
Step by step
The header, claims, and signature are produced in your browser with the Web Crypto API. No secret, private key, or token is transmitted or stored, and nothing is generated during server rendering.
Worked examples
Input
alg HS256, secret "a-string-secret-at-least-256-bits-long"
Result
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.<signature>
The first two segments are readable by anyone. Only the third proves the claims came from a holder of the secret.
Input
Key ID: key-2026-08
Result
{ "alg": "RS256", "typ": "JWT", "kid": "key-2026-08" }The kid tells a verifier which public key from your JWKS to use, which is what makes rotating signing keys possible without downtime.
Reference
| Algorithm | Key | Verifier needs | Typical use |
|---|---|---|---|
| HS256 | Shared secret, 256 bits or more | The same secret | One service signing and verifying its own tokens. |
| HS384 / HS512 | Shared secret | The same secret | As HS256, where a longer HMAC is mandated. |
| RS256 | RSA private key | Only the public key | Identity providers and any multi-service estate. |
| ES256 | EC private key (P-256) | Only the public key | Like RS256 with much smaller signatures. |
| none | No key | Nothing | Never accept it. Historically the source of trivial forgeries. |
Practical Guide
Troubleshooting
FAQ
The signing runs in your browser through the Web Crypto API and nothing is transmitted. Even so, any secret pasted into a web page can be read by browser extensions and lingers in your clipboard. Use a throwaway key for testing and keep production keys in your backend or a secret manager.
HS256 when a single service both issues and verifies. RS256 when several services verify, since they then need only the public key. Match whatever your verifier is configured to expect.
In order of likelihood: the verifier expects a different algorithm, the secret or key does not match, exp has passed, or iss and aud do not match its configuration. The decoder page shows the claims and the expiry conversion.
Not here. Unsigned tokens exist only as an attack against verifiers that trust the header, so this page will not produce one.
An unencrypted PKCS#8 PEM, which starts with BEGIN PRIVATE KEY. If yours starts with BEGIN RSA PRIVATE KEY, convert it: openssl pkcs8 -topk8 -nocrypt -in key.pem -out pkcs8.pem
No. Encoding and signing both use the Web Crypto API in this page. Nothing is uploaded, logged, or stored, and leaving the page discards everything.
Go deeper