What this JWT generator does
A JSON Web Token is three Base64url parts joined by dots: a header that names the algorithm, a payload with the claims, and a signature. This tool builds the header for you, turns your payload into compact JSON, encodes both parts and signs them with HMAC, all with the WebCrypto functions of your browser. The result is a token you can send in an Authorization header to test an API. To read a token you already have, use the JWT decoder.
How the token is encoded
RFC 7515, the JSON Web Signature standard, defines Base64url as Base64 with the URL-safe characters - and _ instead of + and /, and with the trailing = padding removed. The signature is computed over the encoded header, a dot and the encoded payload, exactly as they appear in the token. That is why changing a single character of the payload breaks the signature. The tool was checked against the HS256 example in Appendix A.1 of RFC 7515 and gives the same signature. If you need plain Base64 for something else, the Base64 encoder has a URL-safe mode.
The time and identity claims
RFC 7519 registers short claim names. The buttons above add the most common ones:
- iat (issued at): the time the token was created.
- nbf (not before): the token must not be accepted before this time.
- exp (expiration time): the token must not be accepted on or after this time.
- iss (issuer) and sub (subject): who issued the token and whom it is about.
- aud (audience): who the token is meant for, one string or a list of strings.
All three times are NumericDate values, the number of seconds since 1970-01-01 00:00:00 UTC. To turn one into a readable date by hand, paste it into the Unix timestamp converter.
Choosing a secret
RFC 7518 says the HMAC key must be at least as long as the hash output: 32 bytes for HS256, 48 for HS384 and 64 for HS512. A long random secret is better than a word you can remember. Random secret makes one with your browser's random number generator and ticks the Base64 box, because the random bytes are shown as Base64url text. Give your server the same text and tell it to decode the Base64 first. The password generator makes long secrets too.
How to create a JWT
- 1Pick HS256, HS384 or HS512, the algorithm your server expects.
- 2Edit the payload JSON, then add iat, nbf, exp, iss, sub and aud with the buttons.
- 3Enter the secret or create a random one. The token is signed as you type: copy it, or open it in the decoder to check it.
Sources
- RFC 7519: JSON Web Token (JWT): NumericDate, the registered claims iss, sub, aud, exp, nbf and iat, the typ header value JWT
- RFC 7515: JSON Web Signature (JWS): Base64url without padding, the signing input, the HS256 example in Appendix A.1
- RFC 7518: JSON Web Algorithms (JWA): HS256, HS384 and HS512 and the minimum key length
Frequently asked questions
Is my secret sent anywhere?
No. This tool signs the token with the WebCrypto functions built into your browser. The payload and the secret stay on your device, and the page has no share link, so the secret never ends up in a URL. Still, do not paste a real production secret into any website you do not control, this one included. Use a test secret here and sign real tokens on your server.
Which algorithms can it sign with?
HS256, HS384 and HS512. All three are HMAC with a shared secret, using SHA-256, SHA-384 or SHA-512 as defined in RFC 7518. The same secret signs and verifies the token, so the server that checks it needs that secret too.
How long should the secret be?
RFC 7518 requires a key at least as long as the hash output: 256 bits (32 bytes) for HS256, 384 bits (48 bytes) for HS384 and 512 bits (64 bytes) for HS512. The tool counts the bytes of your secret and warns when it is shorter. Random secret creates one of the right length with your browser's random number generator.
What does "secret is Base64 encoded" mean?
Some systems store the HMAC key as Base64 text and decode it to raw bytes before signing. Tick the box when your secret is stored that way, so the tool signs with the decoded bytes, just like your server. Leave it off when the secret is a plain password-like string.
Why is exp a number and not a date?
RFC 7519 defines exp, nbf and iat as NumericDate values: the number of seconds since 1970-01-01 00:00:00 UTC. The tool fills them in for you and shows the matching date and time below the token.
Can I check the token after I create it?
Yes. Press Open in JWT decoder and the token opens in the decoder on this site, where you can read the claims and verify the signature with the same secret.