JWT Generator

Build, sign, and validate JSON Web Tokens (JWTs) using HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, or ES512.Edit header and payload claims interactively, inspect the decoded token, and verify signature integrity — all in your browser.

The header typically contains the signing algorithm and token type.
Add standard or custom claims. Registered claims: iss, sub, aud, exp, nbf, iat, jti.
For HS algorithms, use a strong secret (≥32 chars). For RS/ES, paste a PEM‑encoded private key.
? Basic HS256
? Custom claims HS256
? RS256 sample (with demo key)
? ES256 sample (with demo key)
⏰ Expired token (HS256)
Privacy first: All JWT operations are performed locally in your browser. No token, key, or payload data is ever sent to any server. Your secrets stay on your device.

Understanding JSON Web Tokens (JWT)

A JSON Web Token (JWT) is a compact, URL‑safe means of representing claims to be transferred between two parties. JWTs are widely used in modern authentication and authorization flows, particularly in OAuth 2.0, OpenID Connect, and RESTful API security. The token is digitally signed (or encrypted) so that the receiver can verify its authenticity and integrity.

JWT = Header Payload Signature

Base64URL(header) . Base64URL(payload) . Base64URL(signature)

The signature is computed over the concatenated header and payload using the chosen algorithm and secret/key.

Why Use JWT?

  • Stateless authentication: The server does not need to store session state; all user information is embedded in the token.
  • Scalability: Perfect for microservices and distributed systems where session affinity is challenging.
  • Compact & URL‑safe: JWTs are small enough to be sent via HTTP headers, query strings, or POST bodies.
  • Self‑contained: The token carries all necessary claims (e.g., user ID, roles, expiration) reducing database lookups.
  • Interoperability: Supported by virtually every programming language and framework.
Case Study: API Gateway with JWT Authentication

A financial services company deployed an API gateway that authenticates incoming requests using JWTs. Each client receives a JWT after logging in, and the gateway validates the token's signature and expiration before routing requests to backend services. This approach eliminated session storage overhead, reduced latency by 40%, and simplified scaling across multiple data centers. The gateway uses RS256 signatures, where the private key is held by the authentication service and the public key is distributed to all gateways. This ensures that only the auth service can issue tokens, while any gateway can verify them without needing the private key.

JWT Structure in Depth

Header

The header typically consists of two fields: alg (the signing algorithm, e.g., HS256, RS256, ES256) and typ (the token type, almost always JWT). Some implementations also include cty (content type) for nested tokens or kid (key ID) to assist with key rotation.

Payload

The payload contains the claims — statements about an entity (typically the user) and additional metadata. Claims are categorized as:

  • Registered claims: Predefined, recommended but not mandatory. Includes iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at), and jti (JWT ID).
  • Public claims: Custom claims that should be defined in the JWT registry or use collision‑resistant names (e.g., https://example.com/role).
  • Private claims: Custom claims agreed upon between the parties, e.g., user_id, role, tenant.

Signature

The signature is created by taking the encoded header and payload, concatenating them with a period, and applying the cryptographic algorithm specified in the header. For symmetric algorithms (HS*), the signature uses a shared secret. For asymmetric algorithms (RS*, ES*), a private key is used for signing and a public key for verification. The signature ensures that the token has not been tampered with and, in the case of asymmetric algorithms, provides non‑repudiation.

Algorithm Comparison

Algorithm Type Key Length Use Case Security Level
HS256 Symmetric (HMAC) ≥ 256 bits Single‑party systems, internal APIs High (if secret is strong)
HS384 Symmetric (HMAC) ≥ 384 bits High‑security internal systems Very high
HS512 Symmetric (HMAC) ≥ 512 bits Maximum security internal systems Extremely high
RS256 Asymmetric (RSA) 2048+ bits Multi‑party systems, microservices Very high (key‑dependent)
RS384 Asymmetric (RSA) 2048+ bits High‑assurance multi‑party Very high
RS512 Asymmetric (RSA) 2048+ bits Maximum assurance multi‑party Extremely high
ES256 Asymmetric (ECDSA) 256 bits (P‑256) Resource‑constrained environments High (elliptic curve)
ES384 Asymmetric (ECDSA) 384 bits (P‑384) High‑security with smaller keys Very high
ES512 Asymmetric (ECDSA) 521 bits (P‑521) Maximum security, compact keys Extremely high
Security Best Practices:
  • Always use strong secrets (≥ 32 random characters) for HS* algorithms.
  • Rotate keys regularly and use kid (key ID) in the header to support key versioning.
  • Set reasonable expiration times (exp) — short‑lived tokens reduce the impact of leakage.
  • Use asymmetric algorithms (RS*, ES*) for multi‑service architectures to avoid sharing secrets.
  • Validate all claims (especially iss, aud, exp) on the receiving side.
  • Never log or transmit JWTs in plaintext over unencrypted channels (always use HTTPS).

How the JWT Generator Works

  1. Header & Payload: You provide JSON objects for the header and payload. The tool validates that each is valid JSON.
  2. Algorithm Selection: Choose from HS256, HS384, HS512 (symmetric) or RS256, RS384, RS512, ES256, ES384, ES512 (asymmetric).
  3. Key / Secret: For HS* algorithms, enter a secret key. For RS*/ES*, paste a PEM‑encoded private key. The tool uses the Web Crypto API for all cryptographic operations.
  4. Token Generation: The header and payload are Base64URL‑encoded, concatenated, and signed using the chosen algorithm and key. The resulting JWT is displayed with color‑coded parts.
  5. Decoding & Validation: Click Decode & Verify to parse an existing JWT, inspect the decoded header and payload, and verify the signature. The tool also performs standard claim validation (exp, iat, nbf).

Real‑World Applications

  • OAuth 2.0 & OpenID Connect: JWTs are the default format for ID tokens and access tokens in modern identity protocols.
  • API Authentication: Securely authenticate requests to RESTful and GraphQL APIs without server‑side session storage.
  • Single Sign‑On (SSO): JWTs enable seamless authentication across multiple applications and domains.
  • Microservices: Pass user context and permissions between services in a stateless manner.
  • Mobile & SPA: Lightweight tokens that work well with mobile and single‑page applications.
  • IoT & Embedded: Compact tokens suitable for constrained devices with limited bandwidth.

Common Misconceptions About JWTs

  • JWTs are encrypted by default: False. JWTs are signed, not encrypted. To encrypt a JWT, use the JWE (JSON Web Encryption) standard.
  • JWTs are always stateless: True by design, but implementations may choose to store state (e.g., token blacklists) when needed.
  • HS256 is less secure than RS256: Not necessarily. The security depends on key management. HS256 is secure if the secret is strong and kept confidential.
  • JWTs are too large: While larger than a simple session ID, the overhead is minimal (typically ~200‑300 bytes) and acceptable for most use cases.
  • You can't revoke JWTs: You can by maintaining a deny‑list (blacklist) or using short expirations combined with refresh tokens.

Rooted in cryptographic standards — This tool adheres to the RFC 7519 (JWT), RFC 7518 (JWA), and RFC 7515 (JWS) specifications. All cryptographic operations leverage the Web Crypto API, ensuring FIPS‑compliant algorithms and hardware‑accelerated performance where available. Reviewed by the GetZenQuery tech team, last updated June 2026.

Frequently Asked Questions

HS256 uses a symmetric key (shared secret) for both signing and verification, making it fast and suitable for single‑party systems. RS256 uses an asymmetric key pair: the private key signs, the public key verifies. This allows multiple parties to verify tokens without sharing the private key, making it ideal for distributed systems and third‑party integrations.

You can generate an RSA private key using OpenSSL: openssl genrsa -out private.pem 2048. For ECDSA: openssl ecparam -genkey -name prime256v1 -noout -out private-ec.pem. Then paste the contents of the PEM file into the key field in this tool. Never share your private key — it must remain confidential.

Yes. This tool runs entirely in your browser using the Web Crypto API. No data is sent to any server. However, for production or sensitive data, always use a trusted environment and consider using offline tools or libraries. Never use an online tool with real production secrets unless you fully trust the implementation.

The tool will mark the token as ✘ Invalid signature. This indicates that the token has been tampered with, the wrong key was used, or the token is corrupted. You should reject such tokens in your application.

Absolutely. Paste any JWT into the tool and click Decode & Verify. The tool will parse the header and payload, and if you provide the correct secret or public key, it will also verify the signature. This is useful for debugging tokens from OAuth providers or third‑party APIs.

JWT (JSON Web Token) is a container format that can be either signed (JWS) or encrypted (JWE). Most JWTs in the wild are JWS — signed but not encrypted. A JWS consists of a header, payload, and signature. A JWE includes encryption of the payload. This tool handles JWS (signed) tokens only.
References: RFC 7519 JWT, RFC 7518 JWA, jwt.io, Web Crypto API, Auth0 JWT Documentation.