CSRF Token Generator

Draw a random CSRF token in hex or URL-safe Base64, so a form submitted from another site can be told apart from one of your own. It is drawn on your device and never leaves your browser.

A CSRF token is a value only your own pages know. Another site can make a visitor's browser send a request to yours, carrying their cookies with it, but it cannot read your pages to find out what to put in this field — so a request that arrives without the right token was not sent by one of your forms. This draws one on your device, in the encoding your framework expects.

Your CSRF token

Strength256 bitsStrong

Customize

Encoding

Base64 (URL-safe)Letters, digits, - and _. The same randomness in fewer characters.HexDigits and a–f. Read by anything, and the longer of the two.

Both write down the same random bytes, so the encoding changes how long the token looks and nothing about how hard it is to guess. Pick whichever one the thing storing and comparing it accepts.

Randomness32

8 bytes64 bytes

Each byte is 8 bits of chance, and this is the only setting that affects strength. 16 bytes (128 bits) is the level a token is expected to reach; 32 is what the frameworks that ship CSRF protection hand out, and the extra characters cost you nothing.

Characters used

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_

All 64 are safe in a form field, a request header and a URL, so the token comes back exactly as it went out and matches the copy your server is holding.

Token length

32 bytes written in Base64 (URL-safe)43 characters

Worth checking against whatever holds the token — it is stored alongside the session and sent back on every protected request — but never a reason to drop below 16 bytes of randomness.

Recent tokens

Nothing here yet. Tokens you generate are kept on this device only, so you can pick one up again if you close the tab before using it.

What makes a CSRF token work

One thing only: that nobody outside your site can work out what the token is. Every byte here is drawn separately, so 32 bytes come to exactly 256 bits. 128 bits is the level a token is expected to reach, and 256 — that is 32 bytes — is what the frameworks with CSRF protection built in already hand out. A token built from the user number, the session, the time of day or a counter is weaker no matter how long it looks, because whoever works out the recipe can then write down everybody else's.

The encoding is a way of writing the bytes down, not a source of strength. The same 32 bytes are 64 characters in hex and 43 in Base64 — two lengths, one level of difficulty for anyone trying to guess it. Choose by what has to carry the token, and leave the strength to the slider above.

Generating one is the easy half. Your server has to keep its own copy against the signed-in session and compare the two on every request that changes something — a token the server merely accepts back is one any site can send. Compare the two in full, not by prefix, and put the token in a hidden form field or a request header rather than in a URL, where it ends up in browser history, in server logs and in the referrer sent to every site you link to.

Give it the same life as the session and issue a fresh one when somebody signs in, so a token handed out beforehand is already dead. It is a second lock rather than the only one: marking your session cookie SameSite stops most forged requests from carrying credentials at all, and the token covers what SameSite does not.

Nothing here is registered with anyone. A token becomes real only when your own server stores it against a session, so generating another is the whole cost of losing one before then.

Everything happens on your device. Your CSRF tokens never leave this browser.