b2KIT

JWT Generator

Create and sign JSON Web Tokens with custom claims, expiration, and HMAC or RSA signing algorithms.

Tested tool guide Tested browser tools Checked August 16, 2026

What JWT Generator does, with a checked example

JWT Generator builds a compact, signed JSON Web Token from a JOSE header, a claim set, and either an HMAC secret or RSA private key. It base64url-encodes the header and payload, joins those segments, and signs that exact content with the selected algorithm. The resulting payload is readable by anyone holding the token; signing detects alteration but does not encrypt claims. A frequent error is supplying an expiration value in milliseconds even though the JWT exp claim uses seconds since the Unix epoch.

Worked example

A concrete input and expected output from the current implementation.

Input

Algorithm: HS256
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}
Secret: your-256-bit-secret

Expected output

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The first two segments are the base64url encodings of the compact header and payload shown above. The final segment is HMAC-SHA-256 over those two joined segments, using the literal UTF-8 secret.

How the result is produced

1

Claims and encoding

The header identifies the selected signing algorithm, while the payload contains claims such as sub, iss, aud, iat, nbf, and exp. Header and payload JSON are separately encoded with base64url and joined by a period. Base64url is an encoding, not confidentiality protection, so names, identifiers, and other payload values remain inspectable.

2

Signature creation

For HMAC signing, one shared secret creates and verifies the signature. For RSA signing, the private key signs and the corresponding public key verifies. Since signing credentials are especially sensitive, it is relevant that this generator performs its work in the browser and does not upload the entered key. The output is a three-segment compact token.

Good uses

  • Create a short-lived test token with controlled sub, aud, and exp claims for an authentication flow.
  • Generate an HMAC-signed JWT while debugging whether two services agree on the secret, algorithm, and exact claim values.
  • Produce an RSA-signed fixture whose signature can be checked with the matching public key in integration tests.

Limits and checks

  • Decoding the header and payload does not verify the signature; a recipient must perform cryptographic verification.
  • The exp, nbf, issuer, and audience claims affect acceptance only when the receiving application validates them.
  • Changing whitespace, claim values, claim order, header content, algorithm, or signing key can produce a different compact token.

Common questions

Does a signed JWT hide its claims?

No. The header and payload use base64url and can be decoded without a secret or private key. The signature lets a verifier detect changes and establish that the signer possessed the required key. Do not place passwords, private keys, or confidential personal data in this token merely because it has a signature.

Can I create an RSA-signed token with only the public key?

No. RSA signing requires the private key. The public key is for verification and cannot produce the corresponding signature. If the intended recipient gives you only a public key, you can use it to check tokens from the private-key holder, but not to mint equivalent signed tokens yourself.

References and verification

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

Related Tools