JWT Generator (HS256)
Create signed HS256 JSON Web Tokens locally in your browser, nothing uploaded.
Loading JWT Generator (HS256)… If nothing happens, please enable JavaScript.
A JSON Web Token, or JWT, is a compact, signed token format used everywhere in modern authentication and authorisation. A JWT packs a header and a payload of claims into two Base64url-encoded segments, then appends a signature that proves the token has not been tampered with. This generator builds a fully valid HS256 token for you: it assembles the standard header, encodes your payload, and signs the result with HMAC-SHA256 using a secret you provide. It is the natural counterpart to a JWT decoder, letting you create the tokens you would otherwise only inspect.
Frequently asked questions
Is my secret or payload sent anywhere?
What is HS256 and how does the signature work?
What should I put in the payload?
How do I add an expiry time?
Is HS256 secure enough for production?
Why did I get an invalid JSON error?
Can I decode the token I just generated?
Does the generator work offline?
About JWT Generator (HS256)
HS256 is the most widely used JWT algorithm. It is symmetric, meaning the same secret is used to both create and verify the signature, which keeps things simple when a single service issues and checks its own tokens. To use the tool, paste a JSON payload containing your claims (common ones include sub for the subject, iat for issued-at, and exp for expiry), enter your signing secret, and click Generate. The tool validates that your payload is well-formed JSON, reports a clear error if it is not, and produces a token in the familiar header.payload.signature form ready to copy.
Signing happens entirely in your browser through the native Web Crypto API, with no external library and no network request. Your payload and, crucially, your secret never leave your device, are never logged, and are never transmitted. Because the secret is the one thing that must stay confidential for HS256 to be secure, doing the work locally is exactly the right approach. The tool also runs fully offline once the page has loaded.
The token format hidden in plain sight
JWTs were standardised in RFC 7519 in 2015, part of a family of JOSE (JavaScript Object Signing and Encryption) specifications. The format is deliberately URL-safe: each of the three segments is Base64url encoded, which swaps the plus and slash characters for dash and underscore so a token can travel in a URL, an HTTP header, or a cookie without further escaping.
A detail that surprises many developers is that the payload of a signed JWT is not encrypted, only encoded. Anyone who intercepts the token can Base64url-decode the middle segment and read every claim inside. The signature guarantees integrity and authenticity, that the token was issued by someone holding the secret and has not been altered, but it does nothing to hide the contents. That is why you should never place passwords or other secrets in a JWT payload.
The most infamous JWT vulnerability involved the algorithm field in the header. Some early libraries trusted the alg value blindly, allowing an attacker to set it to 'none' and strip the signature entirely, or to switch a token from an asymmetric to a symmetric algorithm and forge it using the public key as the HMAC secret. Modern libraries defend against this by requiring the expected algorithm to be specified up front, a lesson that shaped how JWTs are validated today.