JWT Generator

Welcome to the JWT Generator, a fast and free online tool for creating signed JSON Web Tokens. Whether you are testing an authentication flow, building an API, debugging an integration, or learning how JWTs work under the hood, this generator gives you full control over the token header, payload claims, and HMAC signing algorithm. Output a valid HS256, HS384, or HS512 token in one click and inspect every segment side by side.

What Is a JSON Web Token?

A JSON Web Token (JWT) is a compact, URL-safe credential format defined by RFC 7519. A JWT carries claims about a subject between two parties and proves its integrity through a cryptographic signature. Because the token is self-contained, the receiver can validate it without calling back to the issuer — a property that makes JWTs the backbone of stateless authentication for modern web and mobile applications.

Every JWT is built from three base64url-encoded parts joined with dots:

• Header — a JSON object that declares the token type (typ) and the signing algorithm (alg).
• Payload — a JSON object that holds the claims, such as the user id, expiration time, and any custom data.
• Signature — an HMAC or RSA signature over the encoded header and payload that protects them from tampering.

How the JWT Generator Works

This tool follows the exact JWT signing recipe from RFC 7519 §7.1:

1. Serialize the header JSON to its compact form (no whitespace) and base64url-encode it.
2. Do the same for the payload JSON.
3. Concatenate the two with a dot separator. This is the signing input.
4. Compute the HMAC of the signing input using your secret and the chosen SHA-2 algorithm.
5. Base64url-encode the resulting signature bytes.
6. Concatenate everything as header.payload.signature.

What Makes This Generator Different

• Three-segment color visualization — header (rose), payload (purple), signature (cyan) so you can spot each part instantly.
• Quick Claims palette — one-click insertion of iss, sub, aud, iat, nbf, and jti.
• Expiry helper — preset buttons for 1 hour, 1 day, 7 days, or 30 days that compute the correct Unix timestamp automatically.
• Live token preview — the encoded header and payload update as you type so you can see how each edit changes the token.
• Smart header sync — switching algorithm updates the alg field of the header automatically.
• Base64 secret toggle — if your secret is stored as base64 (the JWS convention for binary keys), enable the option and the tool decodes it before signing.
• Per-segment copy buttons — copy the header, payload, signature, or full token independently.
• Claim summary — recognized standard claims are listed with a description and a human-readable timestamp where applicable.

Choosing the Right Algorithm

The three HMAC variants this tool supports are functionally identical except for the underlying SHA-2 hash and signature length:

• HS256 — HMAC with SHA-256. 256-bit signature. The default for almost every JWT-issuing library and the most widely interoperable choice.
• HS384 — HMAC with SHA-384. 384-bit signature. Slightly larger margin against future cryptanalysis.
• HS512 — HMAC with SHA-512. 512-bit signature. Useful when policy requires the longest standard hash.

All three rely on a shared secret that both the signer and verifier hold. RFC 7518 §3.2 requires the key to be at least as long as the hash output: 256 bits for HS256, 384 bits for HS384, 512 bits for HS512.

Standard Registered Claims

RFC 7519 §4.1 defines a small set of standard claims that JWT issuers and verifiers should recognize. They are all optional but widely supported:

• iss (issuer) — identifies who created the token. Often a URL or service name.
• sub (subject) — identifies who the token is about, typically a user id.
• aud (audience) — identifies the recipient the token is intended for. May be a single string or an array.
• exp (expiration time) — Unix timestamp after which the token must be rejected.
• nbf (not before) — Unix timestamp before which the token must not be accepted.
• iat (issued at) — Unix timestamp recording when the token was created.
• jti (JWT ID) — a unique identifier that allows tokens to be revoked or tracked individually.

How to Use This Tool

1. Choose a signing algorithm — click HS256, HS384, or HS512. The header is updated automatically to match.
2. Edit the header (optional) — the default header contains alg and typ. Add a custom kid (key id) if your verifier needs one.
3. Build the payload — type your claims as JSON or click the Quick Claims buttons to insert standard fields. The expiry helper writes a correct Unix timestamp for the relative duration you choose.
4. Set the secret — enter your HMAC shared secret. Toggle the eye icon to reveal it. If your secret is base64-encoded, enable the checkbox so the tool decodes it before signing.
5. Generate the JWT — click Generate JWT. The full token, the three segment cards, the structure diagram, and the recognized-claim summary are rendered together.
6. Copy what you need — use the per-segment Copy buttons or the Copy Token button to take the encoded value into Postman, curl, or your client app.

Common Use Cases

Authentication and Authorization

• Issue access tokens after a successful login.
• Encode user identity (sub) plus role or permission claims.
• Sign short-lived tokens (15–60 minutes) and refresh them as needed.

API Integration Testing

• Build mock tokens to test how your API responds to expired, future-dated, or malformed claims.
• Generate fixture JWTs for unit tests and CI pipelines.
• Reproduce production-like tokens in a local environment without hitting the real auth server.

Single Sign-On (SSO) Debugging

• Compare a known-good JWT to one your provider is sending to find spec drift.
• Check the signing algorithm and key id (kid) used by an upstream issuer.

Frequently Asked Questions

Is the JWT created here a real, valid token?

Yes. The token is signed with HMAC over the canonical encoded header and payload. Any JWT library that uses your same secret will validate it successfully.

Why does my token look identical to what I generate elsewhere?

Because JWTs are deterministic: given the same header, payload, and secret, every conformant library produces the exact same string. If you see a difference, check that the JSON serialization order, key spelling, and secret encoding all match.

Can I decode a JWT to verify what I generated?

Yes. Pair this tool with a JWT decoder to inspect the segments. Decoding only reverses the base64url step — verifying the signature still requires the secret.

Why is my secret rejected as too short?

RFC 7518 recommends a key of at least the hash output length: 256 bits for HS256. The tool itself does not enforce a minimum, but a well-behaved verifier may reject short keys. Use a randomly generated 32+ byte secret in real use.

Does this tool support RS256, ES256, or EdDSA?

Not yet — this tool focuses on HMAC-based algorithms because they need only a shared string. Asymmetric algorithms (RS*, PS*, ES*, EdDSA) require key pairs and PEM handling that are better suited to dedicated tooling.

Are my secret and payload sent to the server?

The form is submitted over HTTPS to compute the signature. Nothing is logged or stored beyond the lifetime of the request. Do not enter production secrets here regardless — treat it as a public testing environment.

Additional Resources

• RFC 7519 - JSON Web Token (JWT)
• RFC 7515 - JSON Web Signature (JWS)
• RFC 7518 - JSON Web Algorithms (JWA)
• JSON Web Token - Wikipedia