ToolKitSphereFree Online JWT Generator (HS256)
Construct and sign a JSON Web Token using HS256 algorithm and a secret key.
61 characters · 8 words · 61 bytes (UTF-8)
Output will appear here
Click in the output to select all text
Related tools
JWT Decoder (Header, Payload, Signature)
Decode and inspect JSON Web Token headers, claims, expiration, and payload data.
HMAC Generator (All Algorithms)
Generate HMAC signatures using SHA-256, SHA-512, SHA-1, or MD5 with a secret key.
Base64URL Encode / Decode
URL-safe Base64 encoding and decoding without padding or special URL characters.
SHA-256 Hash Generator
Generate secure 256-bit SHA-256 hashes for cryptographic verification.
This JWT generator lets you construct custom header and payload claims and sign the resulting token using HS256 with a secret key of your choice, all computed instantly in your browser. Building a valid signed JWT by hand is easy to get wrong — the header and payload need precise Base64URL encoding, and the HMAC-SHA256 signature has to be computed over the exact concatenated string — which makes a dedicated generator genuinely useful for testing API authentication flows, mocking auth tokens in development environments, or simply learning how the three JWT segments fit together. Backend developers testing protected endpoints, QA engineers generating test tokens with specific claims (like an expired 'exp' to test error handling), and students learning the JWT spec will find this tool saves real time over hand-assembling tokens. Your secret key and every claim you enter are processed entirely client-side via the Web Crypto API — nothing is transmitted to a server, which is essential since HS256 signing keys must stay confidential. There's no signup and the signed token updates instantly as you edit claims. Pair this with the JWT decoder to double-check your output, or the HMAC generator to understand the underlying signature mechanism. Scroll down to build and sign your JWT now.
Features
- Constructs custom JWT header and payload claims
- Signs tokens using HMAC-SHA256 (HS256) with your secret key
- Editable standard claims (sub, iat, exp, iss, aud) plus custom fields
- Fully client-side signing, no server transmission of your secret
- Instant Base64URL encoding of header and payload
- One-click copy of the complete signed token
- Live regeneration as you edit claims or the secret key
- Produces standards-compliant, dot-separated JWT output
Why use this jwt token generator (hs256)?
- Instant token generation with live updates
- Fully private — your secret key never leaves your browser
- Standards-accurate HS256 signing matching server-side libraries
- Saves time versus hand-assembling and signing tokens manually
- Free with unlimited use and no signup required
Frequently asked questions
What is HS256 in a JWT?
HS256 means the token is signed using HMAC with SHA-256, a symmetric algorithm where the same secret key is used to both sign and verify the token.
Is it safe to generate real production JWTs with this tool?
The signing happens entirely client-side and your secret never leaves your browser, but for production systems, tokens should generally be issued by your authenticated backend, not a public browser tool — this is best suited for testing and development.
What's the difference between HS256 and RS256?
HS256 uses a single shared secret for both signing and verification (symmetric), while RS256 uses an RSA private key to sign and a separate public key to verify (asymmetric), which is preferable when multiple parties need to verify tokens without holding the signing secret.
What claims should every JWT include?
Common standard claims include 'sub' (subject/user ID), 'iat' (issued-at time), and 'exp' (expiration time); which additional claims you need depends on your application.
Can I create a JWT with an already-expired 'exp' claim?
Yes, this is useful for testing how your application handles expired tokens — set the 'exp' claim to a timestamp in the past.
Does anyone need my secret key to decode this JWT?
No, the payload is only Base64URL-encoded and readable by anyone; the secret key is only required to verify the signature or generate a new valid one, not to read the claims.
Why would my generated JWT fail verification on a server?
The most common cause is a mismatched secret key between what you used here and what the server expects — double-check the exact secret string, including any whitespace.