Why only HMAC (HS256/384/512) and not RS256 or ES256?

Building an RS256/ES256 token needs a private key, and handling private keys in a browser-based builder tool adds real risk of someone pasting a production key into a page. HMAC-based signing only needs a shared secret, which is the common case for building test tokens. Use the RSA/ECDSA Key Generator plus a server-side library if you need to sign with a private key.

Does this tool add standard claims like exp or iat automatically?

No, you write the full payload JSON yourself, including any standard claims (exp, iat, sub, iss, etc.) you want. This keeps the tool predictable: what you see in the payload editor is exactly what ends up in the token.

Is the secret I enter here safe to reuse in production?

Treat any secret you type into a browser tool as compromised for production purposes. This tool is meant for building test tokens during development, not for generating tokens signed with your real production signing secret.

Does this tool send my payload or secret anywhere?

No. The token is built and signed entirely in your browser using @noble/hashes; nothing is transmitted.

JWT Builder - Build and Sign a JSON Web Token

Overview

Introduction

Testing an API that expects a JWT often means needing a real, validly-signed token on hand, without wanting to spin up a whole auth server just to get one.

This tool builds one from a JSON payload you write and signs it with HMAC, entirely in your browser.

What Is JWT Builder?

A JWT builder that takes a JSON payload, wraps it with a standard {alg, typ} header, base64url-encodes both, and signs the result with HMAC-SHA256, SHA384, or SHA512 using a secret you provide.

It's the building counterpart to the JWT Debugger, which decodes and verifies tokens; this tool creates them.

How JWT Builder Works

Your payload JSON is parsed and validated as a JSON object, then combined with a header of `{"alg": "HS256", "typ": "JWT"}` (or HS384/HS512, depending on your selection), and both are base64url-encoded per RFC 7519.

The resulting `header.payload` string is signed with HMAC (via @noble/hashes) using your secret, and the base64url-encoded signature is appended as the token's third segment.

When To Use JWT Builder

Use it to generate a test JWT for developing or debugging an API that expects a bearer token signed with a known shared secret.

It's also useful for understanding exactly how a JWT's three segments are constructed, since you control every part of the payload directly.

Often used alongside JWT Debugger & Signature Verifier, HMAC Generator and RSA/ECDSA Key Generator.

Features

Advantages

Produces a real, correctly-signed JWT you can paste directly into an Authorization header for testing.
Gives full control over the payload JSON, with no hidden or automatically-injected claims.
Supports all three common HMAC strengths (HS256/384/512) in one tool.

Limitations

Only supports HMAC-based signing; RS256/ES256 (private-key-based) signing isn't offered here, to avoid encouraging private keys to be pasted into a browser tool.
Doesn't validate your payload against any particular claim schema; it only checks that it's valid JSON.

Examples

Building a token with a custom claim

Input

payload: {"sub": "user123", "role": "admin"}, secret: "my-secret", algorithm: HS256

Output

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwicm9sZSI6ImFkbWluIn0.4Q9x...

The header and payload are base64url-encoded and joined with a dot, then an HMAC-SHA256 signature over that string becomes the third segment.

Best Practices & Notes

Best Practices

Only use this for building test/development tokens; never paste a real production signing secret into a browser-based tool.
Include the claims your downstream system actually checks (exp, aud, iss, etc.) explicitly in the payload, since none are added automatically.
Verify a token you've built with the JWT Debugger afterward to double-check its structure before using it.

Developer Notes

Signing uses `@noble/hashes/hmac.js`'s `hmac()` with `sha256`/`sha384`/`sha512` from `@noble/hashes/sha2.js` over the UTF-8 bytes of `base64url(header) + "." + base64url(payload)`, matching RFC 7519 §3's JWS Compact Serialization exactly. Base64url encoding strips padding and swaps `+`/`/` for `-`/`_`, per RFC 7515.

JWT Builder Use Cases

Generating a test JWT for developing or debugging an API integration
Producing a token with specific custom claims to test authorization logic
Learning how a JWT's header, payload, and signature segments are actually constructed

Common Mistakes

Pasting a real production signing secret into this (or any) browser-based tool.
Forgetting to include standard claims like `exp` that a downstream system expects, since this tool doesn't add any automatically.

Tips

Copy the built token straight into the JWT Debugger's input to confirm it decodes and verifies exactly as expected before using it elsewhere.

JWT Builder