JWT Encoder & Signer: Real HS256 Signatures for Testing and Debugging
Plenty of 'JWT generator' tools just format text to look like a token without computing a real signature — which is useless for actually testing an API that verifies tokens. This one computes a genuine HMAC-SHA256 signature using the browser's native Web Crypto API, so the token it produces will pass verification against the same secret anywhere else.
Header and payload are JSON objects; the signature covers the exact concatenated encoded string.
Why HS256 Is the Right Fit for a Client-Side Signer
HS256 uses a single shared secret for both signing and verifying — exactly the kind of symmetric operation that's simple and safe to run entirely in a browser tab, since there's no private key that needs special protection beyond the secret string itself. RS256 and ES256 need actual private key material, which changes both the security model and the implementation complexity.
What Actually Gets Signed
The signature doesn't cover the header and payload JSON objects directly — it covers their exact base64url-encoded string forms, concatenated with a period. This is why re-formatting a JWT's JSON (even just changing whitespace) without recomputing the signature invalidates it; the signature is over the encoded bytes, not the logical JSON structure.
Common Claims Worth Setting
iat (issued at) and exp (expiration) are the most commonly checked timestamp claims — most JWT verification libraries reject an expired token automatically. sub (subject) typically identifies the user or entity the token represents. Custom claims (like name in the example) can be anything your application needs, as long as both issuer and verifier agree on their meaning.
Practical Examples
Testing an API's Token Verification
Generating a token your backend should accept.
- 1.Set payload sub/exp to match your test user
- 2.Sign with the same secret your API uses
- 3.Send as Authorization: Bearer
Testing Expiration Handling
Deliberately generating an expired token.
- 1.Set exp to a timestamp in the past
- 2.Sign normally
- 3.Confirm your API correctly rejects it
What This Tool Does
- Real HMAC-SHA256 signing: via native Web Crypto
- Editable header and payload: full JSON control
- Live re-signing: updates as you type
- JSON validation: catches malformed header/payload
Good Use Cases
- Testing an API's JWT verification logic end-to-end
- Generating a token with a specific expired/future timestamp
- Debugging a signature mismatch by comparing against a known-good secret
- Learning exactly what a JWT signature actually covers
Frequently Asked Questions
Is the signature real, or just a formatted placeholder?
It's a real HMAC-SHA256 signature computed via the browser's native Web Crypto API — the exact same algorithm any HS256 JWT library uses. A token generated here will pass verification against the same secret in any standard JWT library.
Why does this only support HS256, not RS256 or ES256?
HS256 is symmetric — a single shared secret both signs and verifies, which is straightforward to compute client-side. RS256/ES256 are asymmetric and need a private key, not just a secret string. Use the JSON Web Key Generator to create an RSA or EC key pair, then a server-side or CLI tool to sign with the private key.
What are iat and exp in the payload?
iat (issued at) is a Unix timestamp marking when the token was created. exp (expiration) is a Unix timestamp after which the token should be considered invalid — most JWT verification libraries automatically reject an expired token by default.
Can I use this to generate real production tokens?
It generates cryptographically valid tokens, but treat this as a development/debugging tool rather than a production token-issuance system — a production auth server should manage secrets, claims, and expiration through your actual backend, not a browser-based generator.
How is the token actually assembled?
header and payload are each JSON-stringified, then base64url-encoded, joined with a period. That combined string is HMAC-SHA256 signed with your secret, and the resulting signature (also base64url-encoded) becomes the third and final segment.
Is my secret sent anywhere?
No, signing happens entirely in your browser via the Web Crypto API — nothing is transmitted.