Generate a JWT

How to use it#

1. Write your claims as JSON in the payload box.
2. Pick an algorithm and how long the token should last.
3. Type the secret your server signs with.
4. Copy the token, or download it.

What the three parts are#

A JWT is three pieces joined by dots. The header says which algorithm signed it. The payload carries the claims, which is whatever your system needs to know: who the user is, what they may do, when the token stops being valid. The third part is the signature over the first two.

The first two parts are base64url, which is encoding and not encryption. Anyone holding the token can read the payload, and the decoder on this site will show it to them. Put nothing in a JWT you would not put on a postcard.

What the signature gives you is tamper evidence. Change a single character of the payload and the signature no longer matches, so a server that checks it knows the token was altered. It cannot stop someone reading the claims, only from changing them unnoticed.

Choosing the algorithm and the secret#

HS256, HS384, and HS512 are the same scheme with a bigger hash each time. HS256 is what almost everything uses and is not the weak link in any realistic system: the secret is. Match whatever your server expects, since a token signed with one and verified against another simply fails.

The secret should be long and random, and at least as long as the hash output: 32 bytes for HS256. A short memorable secret can be brute forced offline by anyone holding one valid token, and there is no signal when somebody starts trying.

These are shared secret algorithms, so anything that can verify a token can also mint one. Where that is not acceptable, RS256 and friends sign with a private key and verify with a public one, which browsers can do but which needs a key pair rather than a password.

The time claims#

Both iat and exp are seconds since the epoch, not milliseconds. Using milliseconds is the single most common way to build a token every library rejects, because an exp in the year 55000 reads as an expiry that has not arrived and some checks refuse it outright.

An expiry is worth setting even for a test token. A JWT stays valid until it expires and there is no list to revoke it from, so a token with no exp is a password that never changes, sitting in whatever log or terminal history it passed through.

A claim you write yourself is left alone. Typing your own exp in the payload means it is used as written rather than being replaced.

This is for testing#

The point of the tool is a token you can paste into a request while building something: a fixture, a curl command, a test that needs an authenticated call. For that, signing in the browser is exactly right, because the secret never leaves the machine.

It is not how your application should mint tokens. That belongs on your server, with the secret in its configuration rather than in a page. If you are pasting a production secret in here, the safer move is to use a test secret and a test key on the server you are calling.