Skip to content
Lizely

JWT Generator

Create a compact HS256 JWT from strict JSON claims with standards-based base64url encoding and browser-native HMAC-SHA-256.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Paste a strict JSON claims object and enter a non-production secret of at least 32 UTF-8 bytes, or generate one for testing.
  2. 2.Generate the HS256 token and review the fixed header, claims, segment lengths, and absence of confidential data.
  3. 3.Copy the token and verify it with the target JOSE library using explicit algorithm, issuer, audience, lifetime, and key policy.

About JWT Generator

JWT Generator creates a compact JSON Web Token using an HS256 JSON Web Signature. Paste a JSON claims object, enter a sufficiently long UTF-8 secret or generate a random development secret, sign, inspect the three compact segments, and copy the token. Claims and key material remain in the current browser tab and are processed with Web Crypto.

The protected header is fixed to alg HS256 and typ JWT. Fixing the algorithm prevents user input from silently selecting none, a mismatched asymmetric algorithm, or another value that the destination does not intend to accept. The claims input must be a strict JSON object. Arrays, null, comments, trailing commas, undefined, NaN, Infinity, and JavaScript expressions are rejected.

The header and compacted claims object are encoded as UTF-8, converted to base64url using the URL-safe alphabet, and emitted without equals padding. The signing input is the encoded header, a period, and the encoded payload. Web Crypto imports the secret as a raw HMAC key with SHA-256 and signs that exact byte sequence. The signature is then base64url encoded as the third segment.

HS256 is a message authentication code, not encryption. Anyone who receives the token can decode its header and claims without the secret. Never put passwords, private keys, personal records, or confidential application data into a JWT merely because it is signed. The signature detects modification only when a verifier uses the correct secret and validates the result.

The secret must contain at least 32 UTF-8 bytes, matching the HS256 key-size floor associated with the 256-bit hash output. Character count and byte count can differ for non-ASCII text. The random button generates 32 cryptographically random bytes and displays them as 64 hexadecimal characters; those characters are used as the UTF-8 HMAC secret. Treat generated values as visible development material, not automatically provisioned production secrets.

This page does not add iat, exp, nbf, iss, sub, aud, jti, or any other claim automatically. NumericDate values are seconds from the Unix epoch, not JavaScript milliseconds. You are responsible for authoritative claim values, expiration policy, issuer and audience naming, clock skew, key rotation, revocation, and replay controls. A syntactically valid token can still be unsafe or unacceptable.

The generator does not verify the token it just created, contact an identity provider, publish a JWK, store a key, select a kid, encrypt claims, or create RS256, ES256, EdDSA, JWE, or an unsecured token. Use a maintained JOSE library in production systems so verification, algorithm allowlists, key discovery, rotation, and error handling live beside the application trust policy.

Copying or displaying a token can expose bearer credentials through clipboard history, screenshots, browser extensions, logs, support tickets, or chat. Use only non-production claims and secrets on this page. If a real secret or active token is pasted into any environment outside its intended boundary, rotate or revoke it instead of assuming the local implementation made disclosure harmless.

Eight RFC 4648 vectors lock the no-padding base64url encoder, including the dash and underscore alphabet. An RFC 4231 HMAC-SHA-256 vector independently verifies Web Crypto output. Additional tests lock the fixed header, compact payload, three-segment construction, claims-object requirement, and minimum key length. Always verify copied tokens with the production library and its explicit algorithm, issuer, audience, and lifetime checks before trusting them.

Methodology & sources

Compacts a strict JSON claims object, fixes the protected header to HS256/JWT, UTF-8 encodes both segments, applies unpadded RFC base64url, signs header.payload with browser WebCrypto HMAC-SHA-256 using a minimum 32-byte secret, and emits three compact segments.

Frequently asked questions

Are JWT claims encrypted?
No. HS256 signs the compact data but does not hide it. Anyone with the token can base64url-decode the header and payload.
Why is the algorithm fixed to HS256?
A fixed algorithm makes the generator's behavior explicit and avoids producing algorithm-confusion or unsecured tokens. Other algorithms require different key types and production libraries.
Can I use the random secret in production?
The random bytes are generated securely, but the value is displayed in the browser. Production secrets should be provisioned, stored, rotated, and audited through the system's secret-management process.

Related tools

Developer Tools guides

View all