JWT Builder & Signer

Build custom JWT tokens with payload editor and sign with HS256/HS384/HS512 secrets locally.

Tested tool guide Tested browser tools Checked August 16, 2026

What JWT Builder & Signer does and how it behaves

JWT Builder & Signer turns an edited JSON claims object into a compact, signed JWT. Select HS256, HS384, or HS512 and supply the shared secret used to create the signature. The payload and secret remain in the browser while the token is built. The important distinction is that signing does not hide the claims: anyone holding the resulting token can decode its header and payload, even though changing either segment without the secret invalidates the signature.

How the result is produced

Compact JWT construction

The protected header identifies the selected HMAC algorithm, while the payload editor supplies the JWT claims object. The complete protected-header JSON object and complete payload JSON object are each serialized and encoded as one unpadded base64url segment. A period separates the encoded header from the encoded payload, producing the signing input used for the final segment.

HMAC signature

For HS256, HS384, or HS512, the signing input is authenticated with HMAC using the corresponding SHA-2 digest and the entered shared secret. The encoded authentication result becomes the token's third segment. Verification requires the same secret bytes and algorithm. This is symmetric signing, so every verifier holding the secret can also create tokens.

Good uses

Create a bearer-token fixture for a development endpoint configured to verify HS256, HS384, or HS512 with a known shared secret.
Build a JWT containing selected registered or private claims when testing authorization, claim parsing, or middleware behavior.
Reproduce a failing HMAC-signed token with a smaller payload so its claims, algorithm selection, and shared secret can be checked independently.

Limits and checks

A readable payload is not a verified payload. Base64url decoding reveals claims without proving that the signature matches the secret.
The builder creates a signature but cannot guarantee acceptance. A recipient may separately enforce expiration, issuer, audience, required claims, clock policy, or an allowed-algorithm list.
Exact bytes matter. Differences in the secret, JSON value types, property order, whitespace serialization, or algorithm can produce a different token even when two decoded payloads look equivalent.

Common questions

Does an HS256, HS384, or HS512 signature encrypt the JWT payload?

No. These algorithms authenticate the encoded header and payload; they do not conceal either one. The claims remain recoverable from the middle segment without the secret. Use the result only where a signed, readable JWT is appropriate. Protect confidential claim data separately rather than treating a signed JWT as encrypted storage.

Why does another JWT builder return a different token for the same claims and secret?

JWT signatures cover the exact encoded header and payload, not merely their interpreted meaning. Different JSON property ordering or serialization can therefore change the first two segments and the signature. Also confirm the selected HS algorithm and the exact secret bytes. Different token strings may still represent equivalent claims, but each must be verified independently.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.