How to use it
- Choose HS256, HS384 or HS512.
- Edit the payload claims, and click “Set iat and exp” to add the current time and an expiry.
- Enter a test secret, or generate a random 256-bit one.
- Copy the signed token. To check a token, switch to “Verify signature”, paste it and enter the secret.
How it works
A JSON Web Token (RFC 7519) has three Base64URL-encoded parts: a header, a payload of claims and a signature. With the HMAC algorithms HS256, HS384 and HS512, the signature is an HMAC with SHA-256, SHA-384 or SHA-512 over “header.payload”, keyed with a shared secret. Anyone with the secret can create and verify tokens.
The tool serialises the header and payload as compact JSON, encodes them, and signs them with crypto.subtle, the Web Crypto API built into your browser. The alg field in the header always matches the chosen algorithm, typ defaults to JWT, and any other header fields, such as kid, are kept. “Set iat and exp” writes the current time as iat (issued at) and adds the chosen lifetime as exp, both in seconds since 1 January 1970 UTC. The result matches other JWT libraries; for example, the classic jwt.io sample token is reproduced exactly.
The secret can be plain text (its UTF-8 bytes are the key) or Base64/Base64URL-encoded bytes, which many frameworks use. The random secret button creates 32 random bytes with crypto.getRandomValues. For HS256, use at least 32 random bytes; short human-chosen secrets can be guessed offline from any token.
Verification decodes the token, checks that it uses an HMAC algorithm, and recomputes the signature with crypto.subtle.verify. It also shows when exp or nbf mean the token is expired or not yet valid. RS256, ES256 and other public-key algorithms are not supported, and verification here does not check issuer, audience or other claims your application may require.
Examples
Testing an API locally
Your development server expects HS256 tokens signed with “dev-secret-change-me”. Set sub to a test user ID, click “Set iat and exp” with 1 hour, enter the secret and send the token in an Authorization: Bearer header.
Checking which secret signed a token
A staging token is rejected. Paste it into “Verify signature” and try the staging secret: “Signature not valid” tells you the token was signed with a different secret or the secret is in a different format (text vs Base64).
Reproducing the jwt.io sample
With header {"alg":"HS256","typ":"JWT"}, payload {"sub":"1234567890","name":"John Doe","iat":1516239022} and secret “your-256-bit-secret”, the token ends in SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c, the same as on jwt.io.
Frequently asked questions
Is my secret sent to your server?
No. Signing and verification run with the Web Crypto API inside your browser, and the secret is not stored or sent anywhere. We still recommend test secrets only, because a real signing secret should never be typed into a website.
Why is the signature invalid although the secret is right?
Check the secret format. Some systems use the text of the secret, others decode it from Base64 first, which gives different key bytes. Also check that the token was not changed and that it uses the same algorithm.
Can I create RS256 or ES256 tokens?
Not with this tool. It supports only the shared-secret HMAC algorithms HS256, HS384 and HS512.
Is the payload encrypted?
No. A signed JWT is only encoded; anyone can decode and read the payload. The signature only proves it was not changed. Do not put passwords or other secrets in the payload.
Privacy
Tokens are created and verified only in your browser with the Web Crypto API. The header, payload, token and secret are not uploaded, stored or included in analytics.