Skip to main content

JWT Generator

Build and sign test JSON Web Tokens — start from a Keycloak-style access or ID token, pick an algorithm, and generate a key pair with PEM and JWKS export. All in your browser.

Everything runs in your browser. Keys, secrets, and tokens are never sent to a server, logged, or stored.
For testing and development only. Do not sign production tokens with keys generated in a web page.
Algorithm & key
Header
{
  "alg": "RS256",
  "typ": "JWT"
}
Payload
Expires in
Signed token
>_ JSON Web Token (JWT)RS256

Signing…

Open in JWT Decoder

The decoder link carries the token and the public JWKS in the URL fragment (#token=…), which browsers never send to a server. The decoder verifies the signature against that JWKS as soon as it opens. The private key never leaves this page.

When you need a test JWT

Real tokens come from your identity provider, but plenty of work happens before one is available — or needs a token your IdP won't easily produce. A signed test token is handy for:

  • Unit and integration tests for an API that validates bearer tokens.
  • Checking how your backend handles an expired token, a missing role, the wrong aud, or a not-yet-valid nbf.
  • Exercising role-based authorization without creating users and role mappings first.
  • Testing key rotation by signing with a new key and a new kid.

Keycloak-style presets

The Keycloak access token preset mirrors what a Keycloak realm issues: iss as a realm URL, azp for the client that requested the token, sid for the session, scope, and roles in realm_access.roles and resource_access.<client>.roles. The ID token preset adds nonce, auth_time, and profile claims, with aud set to the client. Edit anything — the token is re-signed as you type. To see what each claim means, read Get a Keycloak token and read every claim.

Keys, PEM, and JWKS

For asymmetric algorithms the generator creates a key pair in your browser and shows it in four formats: a JWKS document (what an issuer publishes at its certs endpoint — Keycloak serves one at /realms/<realm>/protocol/openid-connect/certs), the public key as PEM, and the private key as PKCS#8 PEM and as a JWK. Host the JWKS file to give a test API a JWKS URL, or load the private key into your own test fixtures. For how a backend should fetch, cache, and rotate those keys, see Validating Keycloak tokens in any backend.

Choosing an algorithm

RS256 is the default in Keycloak and the most widely supported. ES256 and EdDSA produce much smaller signatures for the same security. HS256 uses a shared secret, so every verifier can also mint tokens — fine for a single service, risky across many. For the trade-offs and common pitfalls, see JWT security best practices.

Related tools

Frequently asked questions

Is it safe to generate keys and tokens here?

Keys, secrets, and tokens are created with your browser's built-in WebCrypto API and never leave the page — nothing is sent to Phase Two or any other server, logged, or stored. That said, this is a testing tool: use it for local development, fixtures, and debugging, and keep production signing keys in your identity provider or a key management service.

Which signing algorithms are supported?

HMAC with a shared secret (HS256, HS384, HS512), RSA (RS256, RS384, RS512 and the RSA-PSS variants PS256, PS384, PS512), ECDSA (ES256 on P-256, ES384 on P-384, and ES512 on P-521), and EdDSA with Ed25519.

How do I verify a token I generated?

Click Open in JWT Decoder. The token and its public JWKS are handed over in the URL fragment, which browsers never send to a server, and the decoder verifies the signature as soon as it opens. For HMAC tokens the secret is never put in the link — choose Secret in the decoder and paste it.

Can I use the generated JWKS with my API?

Yes, for testing. Download jwks.json and serve it from any static host or local server, then point your resource server's JWKS URL at it. Tokens signed here carry a kid that matches the key in that JWKS, so standard JWT libraries will pick the right key.

Can I sign with my own key?

Yes. Choose Import my key and paste a PKCS#8 private key (-----BEGIN PRIVATE KEY-----) or a private JWK. RSA, EC P-256/P-384/P-521, and Ed25519 keys are supported. Older PKCS#1 (BEGIN RSA PRIVATE KEY) files can be converted with openssl pkcs8 -topk8 -nocrypt.

What is the kid header for?

The key ID tells a verifier which key in a JWKS signed the token, which is what makes key rotation possible. By default this tool sets kid to the key's RFC 7638 thumbprint — a stable hash of the public key — but you can type any value.