JWT Encoder & Signer
Sign a JWT with any standard algorithm — the key never leaves this page.
Signed in your browser. Secrets and private keys are used by Web Crypto on this page and are never sent or saved. Prefer the generated test keys: a production signing key belongs only in your server’s secret store.
Algorithm & key
PKCS#8 (“BEGIN PRIVATE KEY”), PKCS#1 (“BEGIN RSA PRIVATE KEY”), SEC1 (“BEGIN EC PRIVATE KEY”) or a private JWK.
Public key — give this to whoever verifies the token
“alg” follows the algorithm you chose. Add “kid” if the verifier picks keys by ID.
Issuer, subject and audience
Separate several audiences with commas to get an array. Empty boxes leave the payload unchanged.
Signed token
Check before you use it
About the JWT Encoder & Signer
Create a signed JSON Web Token from a header and a payload you write yourself. Choose any standard JWS algorithm — HS256/384/512 (shared secret), RS256/384/512 and PS256/384/512 (RSA), ES256/384/512 (ECDSA) or EdDSA (Ed25519) — and sign with your own secret, a PEM private key (PKCS#8, PKCS#1 or SEC1), a private JWK, or a test key pair generated on the spot. The token updates as you type.
Signing uses your browser’s Web Crypto API, so secrets and private keys never leave the page and nothing is stored. Helpers set iat, nbf, exp and jti for you, and the page warns about the mistakes that make tokens fail or unsafe: HMAC secrets shorter than RFC 7518 requires, RSA keys under 2048 bits, expiry times in milliseconds, missing exp. It never produces unsigned alg: none tokens. For asymmetric keys you also get the matching public key (PEM and JWK) to give to whoever verifies the token, and one click opens the token in the JWT Decoder.
How to use it
- Pick the signing algorithm. The header’s
algfollows your choice. - For HS algorithms enter the shared secret (as text, Base64 or hex) or press Generate secret. For the others paste a private key in PEM or JWK form, or press Generate test key pair.
- Edit the payload: add your claims (
sub,aud,iss, roles…) and use the buttons foriat,nbf,expandjti. Add akidto the header if the verifier selects keys by ID — Use thumbprint as kid sets the RFC 7638 thumbprint. - Read the warnings, then Copy token, copy it as an
Authorization: Bearerheader, or Open in JWT Decoder to inspect and verify it.
Examples
Header: {"typ":"JWT","alg":"HS256"}
Payload: {"iss":"joe","exp":1300819380,"http://example.com/is_root":true}
Secret (Base64): AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAoweyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.lliDzOlRAdGUCfCHCPx_uisb6ZfZ1LRQa0OJLeYTTpY
Paste these in to get exactly this token (with a warning that its 2011 exp has passed). The RFC’s own token differs only because its JSON contains line breaks, while this page minifies the JSON before signing. The signing code is tested against the RFC’s exact signing input (signature dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk) and the RS256 (RFC 7515 A.2) and Ed25519 (RFC 8037 A.4) examples, byte for byte.
{
"iss": "https://auth.example.com",
"sub": "user-42",
"aud": "api.example.com",
"scope": "read:orders",
"iat": 1790000000,
"exp": 1790000900
}An ES256 token valid for 15 minutes, plus the P-256 public key as PEM and JWK for the API that verifies it.
Common uses
- Testing an API that expects bearer tokens before your identity provider is wired up.
- Reproducing a token your backend issues, to debug a verification error in another service.
- Creating tokens with edge-case claims (expired, not yet valid, wrong audience) for automated tests.
- Learning how JWS signatures work by changing one character and watching the signature change.
- Generating a throwaway RSA, EC or Ed25519 key pair plus a matching JWK for a local JWKS endpoint.
Which algorithm should I pick?
- HS256 — one shared secret signs and verifies. Simple, but every verifier can also create tokens, so use it only when the issuer and the verifier are the same system. The secret must be at least as long as the hash: 32 bytes for HS256, 48 for HS384, 64 for HS512 (RFC 7518 §3.2).
- RS256 — RSA keys of 2048 bits or more (RFC 7518 §3.3); the most widely supported asymmetric choice. PS256 is the same key type with the more modern RSA-PSS padding.
- ES256 — small P-256 keys and short signatures; a good default for new systems.
- EdDSA (Ed25519, RFC 8037) — fast and deterministic, with a small key; check that your verifier library supports it.
Whatever you choose, verifiers should accept only the algorithms they expect (RFC 8725 §3.1).
Claims to include
RFC 7519 defines the registered claims: iss (issuer), sub (subject), aud (audience), exp (expiry), nbf (not before), iat (issued at) and jti (unique token ID). Times are seconds since 1 January 1970 UTC — a value in milliseconds is the most common bug, and this page flags it. Keep access tokens short-lived, always set exp, and remember that the payload is only Base64url-encoded: anyone holding the token can read it, so never put passwords or other secrets in it.
Key formats
Private keys can be pasted as PEM — BEGIN PRIVATE KEY (PKCS#8), BEGIN RSA PRIVATE KEY (PKCS#1) or BEGIN EC PRIVATE KEY (SEC1, as written by openssl ecparam -genkey) — or as a private JWK containing d. Passphrase-protected keys (BEGIN ENCRYPTED PRIVATE KEY) must be decrypted on your own computer first, for example with openssl pkey -in key.pem -out plain.pem. The public key shown under the private key is derived from it in the browser.
Limitations
- Only signed tokens (JWS compact serialization). Encrypted tokens (JWE), unsigned
alg: nonetokens and unencoded payloads (RFC 7797) are not produced. - Algorithms that browsers’ Web Crypto does not offer — ES256K (secp256k1) and Ed448 — are not available. EdDSA needs a recent browser with Ed25519 support.
- The header and payload are minified before encoding; key order and number literals are kept exactly as you typed them.
- Generated test keys exist only on this page. Copy them before you leave — they are never saved.
Privacy
Secrets, private keys, headers and payloads are processed only by your browser’s Web Crypto API on this page. They are never sent to a server or saved; only your choice of algorithm, secret format and token lifetime is remembered on this device.
Frequently asked questions
Is it safe to paste a real private key here?
The key is used only inside your browser and never sent anywhere — but a production signing key should live only in your server’s secret store, and pasting it into any web page is a habit worth avoiding. Use Generate test key pair or a key made for testing.
Why does it warn that my HMAC secret is too short?
RFC 7518 §3.2 requires an HMAC key at least as long as the hash output — 256 bits (32 bytes) for HS256. Short secrets such as secret or your-256-bit-secret can be guessed offline from a single token. Generate secret creates a random secret of the right length.
How do I verify the token I created?
Press Open in JWT Decoder and enter the same secret (HS algorithms) or the public key shown here (all others). Any standard JWT library verifies it too — the signatures follow RFC 7515 and RFC 7518 exactly.
Can I create a token without a signature (alg none)?
No. Unsigned tokens can be forged by anyone: RFC 7518 §3.6 says implementations must not accept them by default, and RFC 8725 §3.2 says libraries should not create them unless explicitly asked. This tool always signs.
Why is my ES256 signature different every time?
ECDSA and RSA-PSS signatures include fresh randomness, so signing the same token twice gives different — but equally valid — signatures. HS, RS and EdDSA signatures are deterministic: the same input and key always give the same token.