JWT Encoder & Generator

Sign tokens with this JWT encoder

This jwt encoder turns a JSON object of claims into a compact, signed JSON Web Token (JWS). You provide the payload on the left, a secret or private key on the right, and the tool builds the header, Base64URL-encodes both parts and signs them with the algorithm you choose. It is handy for testing an API locally, reproducing a bug report or creating fixtures for automated tests.

What goes into a signed JWT?

A JWT has three dot-separated parts: header.payload.signature. The header generated here is always {"alg": "…", "typ": "JWT"}, plus a kid member when you fill in the Key ID field. The payload is your claims object exactly as you typed it, with iat and exp added only if you ask for them.

The signature covers the first two parts. Anyone can read a JWT, so never put passwords or other secrets in the claims. The signature only proves that the token was not changed and was created by someone holding the key.

Example

Signing the sample claims with HS256 and the secret your-256-bit-secret produces this token:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.reGQzG3OKdoIMWLDKOZ4TICJit3EW69cQE72E2CfzRE

The status line also reports "warning: secret is shorter than 256 bits", because that sample secret is only 19 bytes. RFC 7518 asks for an HMAC key at least as long as the hash output.

Options explained

• Algorithm: HS256, HS384 and HS512 use a shared secret. RS256, RS384, RS512 and PS256 need an RSA private key. ES256, ES384 and ES512 need an EC key on P-256, P-384 or P-521. EdDSA needs an Ed25519 key.
• Expires in (seconds): adds an exp claim that many seconds after iat, or after the current time when there is no iat. Leave it at 0 for no expiry.
• Add "iat": sets the issued-at claim to the current Unix time, unless your payload already has one.
• Key ID: writes a kid header so the verifier can pick the matching key from a JWKS.
• Secret is Base64 encoded: decodes the secret to raw bytes before signing. Tick this when your server stores the secret as Base64, as many frameworks do.

Which keys are accepted?

For asymmetric algorithms, paste a PEM private key. PKCS#8 (BEGIN PRIVATE KEY), PKCS#1 (BEGIN RSA PRIVATE KEY) and SEC1 (BEGIN EC PRIVATE KEY) all work, because PKCS#1 and SEC1 keys are wrapped into PKCS#8 before import. A private JWK in JSON form is also accepted. Need a key to test with? Create one with the RSA key generator or the ECDSA and Ed25519 key generator.

Common errors and fixes

• "Signing needs a PRIVATE KEY": you pasted a public key or a certificate. Only the private half can sign.
• "Payload must be a JSON object": the payload must be an object, not an array or a string. Quote all keys and remove trailing commas.
• Wrong key type: an RSA key cannot sign ES256 and an EC key cannot sign RS256. Match the algorithm to the key.
• Token rejected by your server: check that both sides treat the secret the same way (plain text or Base64) and that exp is still in the future.

To inspect the result, paste it into the JWT decoder. To confirm the signature against a public key, use the JWT verifier.

Privacy

Tokens are signed in your browser with the open-source jose library and WebCrypto. Your claims, secrets and private keys are not uploaded. Even so, use test keys here rather than production signing keys.