Building the three-part structure without a real signature
With the header {"alg":"HS256","typ":"JWT"} and payload {"sub":"123","name":"Ada","iat":1710000000}, this generates an unsigned mock token: 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiQWRhIiwiaWF0IjoxNzEwMDAwMDAwfQ' -- the base64url-encoded header and payload joined by a period, with no third signature segment attached.
A real JWT has three dot-separated parts: header, payload, and a cryptographic signature computed over the first two using the secret and algorithm specified in the header. This tool builds the first two parts correctly (properly base64url-encoded JSON) but stops there rather than computing a real HMAC signature, which is why the status reads 'unsigned mock' rather than 'signed'.
Decoding the two segments shown confirms they're standard base64url JSON exactly as a real JWT library would produce -- the structure is correct, only the cryptographic signing step is intentionally skipped.
Why this deliberately isn't production-ready
Mock signer only. Not a production JWT library and not for real auth tokens. A JWT's entire security guarantee comes from the signature -- without a real, correctly-computed HMAC (or RSA/ECDSA) signature verified server-side, a token can be trivially forged, so a token from this tool should never be accepted as proof of identity or authorization by any real system.
This tool exists to let you inspect and understand JWT structure (what the header and payload look like once encoded) for learning, debugging, or building test fixtures -- not to generate tokens your application actually trusts.
For real applications, JWT signing needs to happen server-side using a properly managed secret (for HMAC) or private key (for RSA/ECDSA), using a maintained, audited JWT library in your application's actual language and framework.
Related token and signature tools
To decode and inspect a real JWT you already have (rather than build one), the JWT Decoder is the matching tool for that direction.
If you specifically need a real, verifiable HMAC-SHA256 signature computed in-browser (for testing a webhook signature, for example), the HMAC Signature Generator uses the browser's actual SubtleCrypto API rather than a mock.
Frequently Asked Questions (FAQ)
Why does this generate an 'unsigned mock' token instead of a real signed JWT?
It base64url-encodes the header and payload JSON correctly (the first two parts of a real JWT) but deliberately doesn't compute the third part -- the cryptographic signature -- since doing that securely requires careful secret handling this quick browser tool isn't designed to provide.
Can I use a token from this tool for real authentication?
No. Mock signer only. Not a production JWT library and not for real auth tokens. Without a real, verified signature, any party can forge or alter a token's contents. Use a maintained JWT library on your actual server for anything involving real authentication or authorization.
What is this tool actually useful for?
Inspecting and understanding JWT structure -- seeing exactly how a header and payload get base64url-encoded and joined -- which is useful for learning, debugging an integration, or building test fixtures that don't need real cryptographic verification.
What's the difference between the header and payload in a JWT?
The header specifies the signing algorithm and token type (like {"alg":"HS256","typ":"JWT"}). The payload carries the actual claims -- data about the subject, like the user id, name, and issued-at timestamp in this example.
Does entering a secret in this tool produce a real HMAC signature?
No, this generator's output stays an unsigned mock regardless of whether a secret is entered. For an actual computed HMAC-SHA256 signature using the browser's real cryptography API, use the separate HMAC Signature Generator tool instead.
