🔐 JWT Generator and Validator

📋 Presets

🔧 Algorithm

HMAC (HS*) verifies server-side too. RSA/ECDSA/EdDSA sign in your browser via WebCrypto; the private key never leaves this page.

📦 Claims

🔑 {{ keyLabel }}

Plain UTF-8 string. For HS256, a 32+ byte secret is recommended. PEM-encoded PKCS#8 private key. Never paste a production key here.

📤 Generated token

Configure claims and click "Sign token" to generate.

📑 Header

{{ generatedHeader }}

📄 Payload

{{ generatedPayload }}

🔧 Mode

🎫 Token

🔑 Secret & expected claims

🛡️ Status

{{ validationStatusText }}
  • {{ e }}

📑 Header

{{ decodedHeaderJson }}

📄 Payload

{{ decodedPayloadJson }}

📌 Claim breakdown

Claim Meaning Value
{{ row.k }} {{ row.note }} {{ row.v }}

🧩 Custom claims

{{ row.k }} {{ row.v }}

⚠️ Warnings

  • {{ w }}
Paste a JWT to decode it. Live decoding fires 150ms after you stop typing.
⚠️

ℹ️ About JWT Generator / Validator

What a JSON Web Token is and how it works

A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe credential format defined by RFC 7519. It carries a JSON payload of claims (statements about an entity, like "this user is alice, valid until 2025-12-01T00:00:00Z") that has been digitally signed so the recipient can trust it without calling back to the issuer. JWTs are the foundation of OAuth 2.0 bearer tokens, OpenID Connect ID tokens, service-to-service auth, and most modern session implementations that aim to be stateless.

A signed JWT (a JWS — JSON Web Signature, RFC 7515) has three base64url-encoded segments joined by dots: HEADER.PAYLOAD.SIGNATURE. The header declares the algorithm (alg) and key id (kid); the payload carries the claims; the signature covers HEADER.PAYLOAD and is produced with a secret (HMAC) or a private key (RSA / ECDSA / EdDSA).

Algorithm strength ratings

JWT supports several signature algorithms (see RFC 7518 — JSON Web Algorithms). They are not equivalent. The table below summarises the modern security position; pick a row that matches both the threat model and the operational constraints.

  • HS256 (HMAC-SHA-256) — Adequate. Symmetric, fastest, simplest. Both signer and verifier share the secret. Use only between parties that already trust each other (a service signing tokens it later verifies itself, or two backends sharing a vault). 256-bit MAC strength. NIST-approved. Do not use across trust boundaries.
  • HS384 / HS512 — Strong. Same model as HS256 with 384/512-bit MAC strength. Use for long-lived tokens or where defense-in-depth against future hash weakening matters.
  • RS256 (RSA-PKCS1-v1_5 SHA-256) — Strong. Asymmetric: issuer signs with a private key, recipients verify with a public key. The OpenID Connect default. RSA keys MUST be at least 2048 bits; 3072+ preferred for long-term safety. Larger signatures than ECDSA.
  • RS384 / RS512 — Strong. Same as RS256 with stronger hash. Use when matching infrastructure that already standardised on SHA-384/512.
  • ES256 (ECDSA-P-256 SHA-256) — Strong. Asymmetric, smaller keys, smaller signatures (~64 bytes raw R||S per RFC 7515 §3). NIST-approved curve P-256. Excellent fit for resource-constrained verifiers and tokens carried in cookies/headers.
  • ES384 / ES512 — Strong. Same as ES256 with larger curves. ES512 uses P-521 (not P-512 — common source of confusion).
  • EdDSA (Ed25519, RFC 8037) — Excellent. Deterministic, side-channel-resistant, smallest signatures (64 bytes), fastest verification, no per-signature nonce risk. The modern default when both ends support it. Adopted by SSH, Tor, modern PKI.
  • alg=none — NEVER USE. Removes the signature entirely. A token with {"alg":"none"} MUST be rejected by all verifiers (see the CVE-2015-9235 family of JWT library bypasses where an attacker could remove the signature and have it accepted). This tool always flags alg=none tokens with a critical warning.

OWASP / NIST recommendation: for new systems, prefer EdDSA (Ed25519) when both ends support it, fall back to ES256, then RS256. Use HMAC families only within a single trust boundary.

Standard claims (RFC 7519 §4.1)

  • iss — Issuer. The principal that issued the token (§4.1.1).
  • sub — Subject. The principal the token is about (§4.1.2).
  • aud — Audience. The intended recipient(s); string or array (§4.1.3).
  • exp — Expiration time (NumericDate, seconds since epoch). MUST NOT be accepted after this (§4.1.4).
  • nbf — Not before. MUST NOT be accepted before this (§4.1.5).
  • iat — Issued at. The time the token was minted (§4.1.6).
  • jti — JWT ID. Unique identifier; useful for replay protection (§4.1.7).

Common use cases

  • OAuth 2.0 access tokens for stateless API auth — verify on every request without a DB lookup.
  • OpenID Connect ID tokens — RS256-signed identity assertions from an OIDC IdP.
  • Service-to-service authentication in microservice architectures — short-lived HS256/EdDSA tokens with tight aud scoping.
  • Password reset / email verification links — single-use tokens with short exp and unique jti.
  • API keys (with structure) — long-lived tokens with scope and jti claims, revokable via a denylist of jti values.

Validation checklist

When a verifier accepts a JWT it MUST:

  • Reject tokens with alg=none or an unexpected algorithm.
  • Verify the signature with the key that matches kid (or the pinned key).
  • Check exp — token is expired if exp + leeway < now.
  • Check nbf — token is not yet valid if nbf - leeway > now.
  • Check iss matches the expected issuer.
  • Check aud contains the verifier's identity.
  • Validate any tool-specific custom claims (scopes, roles, tenant id).

This tool performs all of the above in the Validate / Decode tab. For HMAC algorithms the signature is verified in-page and on the server (the same TypeScript module runs in both places). For asymmetric algorithms verification is performed in the browser via WebCrypto because private/public keys should not be transmitted over the wire.

Source references

  • RFC 7519 — JSON Web Token (JWT).
  • RFC 7515 — JSON Web Signature (JWS).
  • RFC 7518 — JSON Web Algorithms (JWA).
  • RFC 8037 — CFRG curves (Ed25519/X25519) for JOSE.
  • RFC 8725 — JSON Web Token Best Current Practices (BCP).
  • jwt.io — interactive debugger with algorithm reference.

API Usage Example:

POST /api/tools/security/jwt-generator-validator
Content-Type: application/json

{
    "operation": "decode",
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
}
Ready