61 characters · 8 words · 61 bytes (UTF-8)
Output will appear here
Click in the output to select all text
61 characters · 8 words · 61 bytes (UTF-8)
Output will appear here
Click in the output to select all text
Decode and inspect JSON Web Token headers, claims, expiration, and payload data.
Generate HMAC signatures using SHA-256, SHA-512, SHA-1, or MD5 with a secret key.
URL-safe Base64 encoding and decoding without padding or special URL characters.
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.
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.
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.
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.
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.
Yes, this is useful for testing how your application handles expired tokens — set the 'exp' claim to a timestamp in the past.
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.
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.