Is this a real, valid JWT?

The structure is real: the header and payload are genuine JSON encoded with proper URL-safe base64url and no padding. The signature, however, is random bytes, so the token will fail cryptographic verification by design.

Why is the signature random?

A valid signature requires a secret or private key you control. Since the goal is testing how your code reads a token rather than trusting it, the tool fills the signature segment with correctly sized random base64url instead of signing.

What claims are included?

The payload includes sub, name, iat, nbf, exp, jti, iss, and aud. The iat and nbf are set to now and exp is now plus your chosen minutes, so you can test both valid and expired tokens.

How do I make an already-expired token?

Set the expiry to a small value and wait, or note that exp is computed from the current time. For immediate expiry testing, generate with a 1-minute window and let it lapse, then check your handler rejects it.

Does anything leave my browser?

No. Encoding uses the browser's built-in base64 and crypto functions, so tokens are generated locally and nothing is transmitted.

What is the JWT-Format Token Generator?

Generate JWT-format tokens with a real base64url-encoded header and payload plus a random signature, in the standard three-part dot-separated format. Configure the algorithm, subject, and expiry to test JWT parsing, display, and expiry logic in your app. It runs free in your browser on Gera Tools, with nothing uploaded.

JWT-Format Token Generator

Name: JWT-Format Token Generator
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

The JWT-Format Token Generator builds tokens in the exact three-part shape of a JSON Web Token — header.payload.signature, each segment base64url-encoded and joined by dots. It is meant for testing how your application parses, displays, and reacts to tokens, not for issuing real credentials.

How it works

A JWT has three segments. This tool builds them like this:

Header — a small JSON object such as {"alg":"HS256","typ":"JWT"}, encoded with URL-safe base64 (the + and / characters become - and _, and trailing = padding is stripped).
Payload — a claims object with sub, name, iat, nbf, exp, jti, iss, and aud. The exp claim is set to the current time plus your chosen minutes.
Signature — random bytes sized to match the algorithm (32 for HS256, 48 for HS384, 64 for HS512), then base64url-encoded.

Because the signature is random rather than computed from a secret, the token is structurally valid but cryptographically invalid.

Claims in the payload

Claim	Meaning	Set to
`sub`	Subject — the user or entity the token represents	Your entered subject value
`iat`	Issued at — Unix timestamp of issue	Current time
`nbf`	Not before — token not valid before this time	Current time
`exp`	Expiry — Unix timestamp of expiration	Now + chosen minutes
`jti`	JWT ID — unique token identifier	Random UUID
`iss`	Issuer	`demo-issuer.example.com`
`aud`	Audience	`demo-api.example.com`

The decoded payload is shown below the token so you can confirm exactly what your parser extracts from each dot-separated segment.

Algorithm and signature size

Different algorithms produce different signature lengths. Choosing HS256 means the random signature is 32 bytes (256 bits), HS384 gives 48 bytes, and HS512 gives 64 bytes. The tool sizes the random fill to match, so a decoder that checks the expected signature length will still see the right number of bytes — even though the bytes themselves are not a real HMAC.

Common testing scenarios

Decoding and display: paste the token as a Bearer value and verify your client reads sub, name, and exp from the payload correctly. Most bugs here are base64url-decoding mistakes or missing padding-strip logic.
Expiry handling: set a short window (for example 1 minute), generate, then wait for the clock to pass exp. Confirm your middleware rejects the token with 401 Unauthorized and not 500.
Switching algorithms: switch between HS256, HS384, and HS512 to confirm your header parser reads the alg field and routes to the right validation branch.
Claim rendering: set specific sub and name values to test your profile-page logic that reads from the token rather than a database call.

Tips and notes

The decoded header and payload are shown below the token so you can confirm exactly what your parser will see.
Use the generated token as a Bearer value to test that your client stores, decodes, and renders claims correctly.
To exercise expiry handling, generate with a short window and verify your code rejects the token once exp passes.
This is never a substitute for a real signed token in production — anything checking the signature will and should reject it. Never use it to authenticate real requests.