Skip to content
JWT & keys

JWKS Generator

Generate 2048-bit RSA key pairs, manage kid values, and create JWKS (JSON Web Key Sets)
containing public keys only. You can also sign RS256 JWTs using the generated private key, inspect the payload, and copy keys, JWKS, or tokens with a single click.

Guide: How to use & features

  • Optionally enter a kid, then click “Generate 2048-bit RSA keys” to create the key pair and JWKS.
  • Copy the public key as a JWKS (JSON Web Key Set) and keep the private key in PKCS#8 PEM format.
  • Edit the payload JSON and click “Create JWT” to generate an RS256-signed token.

Samples: Sample input & output

Publish an RSA key

Input

Algorithm: RS256
Key ID: demo-key

Output

{
  "keys": [
    {
      "kty": "RSA",
      "kid": "demo-key",
      "alg": "RS256",
      "use": "sig",
      "n": "u0fKsY6LQyqQy1vny7H2X7bqY7HWe8soT0x6XPrmT5w",
      "e": "AQAB"
    }
  ]
}

FAQ: FAQ

  • What is a JWKS, and what is the kid for?

    A JWKS (JSON Web Key Set) is a JSON set of keys used to distribute the public keys that token verifiers need. The kid (Key ID) names each key; matching the kid in a JWT header against the keys in the JWKS lets verifiers pick the right key even after you rotate keys.
  • Does the generated JWKS contain the private key?

    No. A JWKS contains public keys only; the private key (PKCS#8 PEM) is shown separately. Only the signer should keep the private key, secured — the public key is the only part safe to publish in a JWKS. Key generation and signing all happen in your browser and are never sent anywhere.
  • How does RS256 (used here) differ from HS256?

    RS256 is asymmetric RSA signing: you sign with the private key and verify with the public key, so you only distribute the public key to verifiers — ideal when there are many verifiers. HS256 is symmetric, signing and verifying with one shared secret, which is simpler but requires everyone to hold the same key.

Use cases: Common use cases

  • Validating key sets

    Fetch JWKS endpoints to inspect kid and alg values and confirm the expected signing algorithms.

  • Checking rotation status

    See whether old and new keys coexist to catch timing gaps between issuers and verifiers.

  • Sharing debug details

    Format the fetched JSON for teammates when troubleshooting integrations with external IdPs.

Notes: Notes & limitations

  • Work stays in your browser

    Inputs and outputs remain local. Closing the tab or clearing cache will remove any temporary state.

  • Validate critical data

    Results are helper outputs—double-check them before sending to production systems or sharing externally.

  • Large payloads depend on your device

    Very large text or files can feel slow in some browsers. Use a desktop environment for heavy workloads.

Keys are created locally and never uploaded anywhere.

Current kid -

The JWKS contains only the public key.

RS256 signature uses the generated private key.

JWKS & RSA Key Pair Generator

Instantly generate JSON Web Key Sets (JWKS) and RSA key pairs (public/private keys) directly within your browser.
This security tool is invaluable when mocking authentication servers adhering to OIDC (OpenID Connect) and OAuth 2.0. It saves you the hassle of running manual OpenSSL commands locally, allowing you to quickly set up token signing verification for your test endpoints.

Articles for this tool

Recent Articles

Use Case
2026-08-07

curl Options Cheat Sheet: What -X, -H and -d Actually Do

A reference for the curl options you meet in real API work: why -d already implies POST, how -d differs from --data-raw, the @ prefix that silently reads a file, single vs double quotes, and why -k and -L deserve more caution than they usually get.

Introduction
2026-08-06

Converting Between JSON Schema and Zod: How required Maps to .optional()

Inside a two-way converter that turns JSON Schema into a Zod schema and Zod code back into JSON Schema. Covers the inverted defaults between required and .optional(), the constraint mapping table, and how the Zod side is parsed without executing any code.

Use Case
2026-08-06

SQL Clause Order Reference: Why WHERE Can't See Your SELECT Alias

The order you write SQL clauses is not the order the database runs them. A reference for the logical execution order (FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT), why aliases fail in WHERE, when to use WHERE vs HAVING, and the MySQL/PostgreSQL differences that bite.

Use Case
2026-08-06

Unified Diff Format Reference: Reading @@ Hunks in git diff Output

How to read the unified diff format git produces: what the four numbers in @@ -12,7 +12,9 @@ mean, why a one-character edit shows as a whole-line replacement, the whitespace and line-ending traps, \ No newline at end of file, combined @@@ diffs on merges, and rename detection via similarity index.

Use Case
2026-08-06

UTC to JST Reference: The 9-Hour Offset, Cheat Sheet & Timezone Pitfalls

Convert between UTC and JST (Japan Standard Time) with a cheat sheet. Covers what Z and +09:00 mean in ISO 8601, when JavaScript date parsing silently shifts by 9 hours, MySQL/PostgreSQL timezone behavior, and why GitHub Actions cron always runs in UTC.

Use Case
2026-08-04

CREATE TABLE Reference: MySQL vs PostgreSQL vs SQLite Types & Constraints

A cross-database CREATE TABLE (DDL) reference with cheat sheets for data types, auto-increment keys (AUTO_INCREMENT / IDENTITY / rowid), foreign key ON DELETE behavior, and the CHECK constraint that MySQL silently ignores.

Ad

Ad