CSRF Token Generator

A Cross-Site Request Forgery (CSRF) attack tricks an authenticated user's browser into sending an unwanted request to your server. For example, if a user is logged into their bank, a malicious page could cause their browser to submit a transfer request — using the user's session cookie — without the user knowing. Because the request comes from the authenticated browser, the server may execute it.

A CSRF token is a secret, random value tied to a user's session that must be submitted with every state-changing request (POST, PUT, DELETE, PATCH). Since the attacker's page cannot read the token from your domain (blocked by same-origin policy), any forged request they submit will be missing the token. The server rejects requests without a valid token, stopping the attack.

Both encode the same underlying random bytes — the choice is a matter of context. Hex (e.g. a3f2c1...) is completely safe in any HTML attribute, URL, or header. Base64URL (e.g. o_LC1...) is about 25% shorter and is safe in URLs and cookies without additional encoding. Use hex for simplicity in HTML forms; use Base64URL in compact APIs or when token size matters.

NIST SP 800-63B and OWASP both recommend at least 128 bits (16 bytes) of entropy, with 256 bits (32 bytes) providing a strong security margin. This tool defaults to 32 bytes. Longer tokens provide negligible additional security in practice — the bottleneck is always the randomness quality, not the length.

Store the token in the user's server-side session (not a plain cookie). On each form render, write the token into a hidden field. On each POST/PUT/DELETE, read the submitted token and compare it to the session value using a constant-time string comparison (to prevent timing attacks). Regenerate the token after each successful login to bind it to the new session.