CSRF Token Generator

CSRF (Cross-Site Request Forgery) is an attack where a malicious website tricks a logged-in user's browser into making an unintended request to another site — for example, submitting a form or transferring funds. A CSRF token is a secret, random value tied to the user's session. Your server generates it, embeds it in forms, and validates it on every state-changing request (POST, PUT, DELETE). Because attackers on other origins can't read your page's content, they can't obtain the token and the forged request is rejected.

32 bytes (256-bit) is the standard recommendation and provides ample security for virtually all applications. 16 bytes (128-bit) is still considered secure and matches what many frameworks use internally. 64 bytes offers extra margin but yields unnecessarily long token strings without a practical security benefit. The key requirement is that tokens are generated with a cryptographically secure random number generator — the length matters less than the source of randomness.

All three formats encode the same random bytes — only the representation differs. Hex uses characters 0-9 and a-f, producing a string twice as long as the byte count (32 bytes → 64 chars). It's easy to read and safe in all contexts. Base64 uses A-Z, a-z, 0-9, +, / and = padding (32 bytes → ~44 chars). Base64url replaces + with - and / with _, and omits padding, making it safe for URLs, HTTP headers, and cookies without additional encoding. For CSRF tokens embedded in HTML forms or HTTP headers, base64url is the most convenient choice.

No — if your API exclusively uses Authorization: Bearer <token> headers (not cookies) for authentication, CSRF is not a concern. Browsers enforce the Same-Origin Policy on custom headers: a cross-origin page cannot set an Authorization header on a fetch/XHR request without first passing a CORS preflight, which your server controls. CSRF exploits cookie-based authentication because browsers automatically attach cookies to cross-origin requests. If you use cookies for auth, even for an API, you need CSRF protection.

SameSite=Strict prevents browsers from sending the cookie on any cross-site request, which effectively blocks most CSRF attacks in modern browsers. However, OWASP still recommends keeping CSRF tokens as a defense-in-depth layer because: (1) SameSite support varies across older browsers and certain mobile WebViews, (2) same-site subdomain vulnerabilities can bypass SameSite in some configurations, and (3) some browsers have known SameSite bugs. Using both SameSite and CSRF tokens gives you two independent protection layers.