// generate cryptographic tokens for form protection
Generate cryptographically secure CSRF tokens for form protection. Choose token length, encoding format, and quantity. Free, browser-based, no signup required.
Tokens are generated server-side using PHP's random_bytes() — a CSPRNG. Nothing is logged or stored.
Token will appear here
Configure options and click GenerateChoose byte length (32 is standard) and how many tokens to generate at once.
Hex for most backends, Base64URL for JSON APIs, Alphanumeric for restricted inputs.
Copy individual tokens or all at once. Download as .txt for use in config files.
CSRF (Cross-Site Request Forgery) tokens are secret, random values embedded in HTML forms or HTTP headers to verify that a request was intentionally made by the authenticated user — not forged by a malicious third-party site. This tool generates cryptographically strong tokens using PHP's random_bytes().
A secure CSRF token must be generated from a cryptographically secure pseudo-random number generator (CSPRNG). This tool uses PHP's random_bytes(), which draws entropy from the OS-level CSPRNG (/dev/urandom on Linux). Predictable tokens — such as those based on timestamps or weak random functions like rand() — can be guessed by attackers.
A minimum of 16 bytes (128 bits) is considered secure for most applications. 32 bytes (256 bits) is a widely adopted standard and provides a comfortable security margin. Longer tokens offer no practical benefit — the bottleneck is always the randomness quality, not the length beyond 32 bytes.
Hex is the safest choice — only [0-9a-f], no special characters, works in every context. Base64URL is more compact and safe for URLs and JSON. Base64 includes +, /, and = which may need URL-encoding. Alphanumeric is useful for environments with strict character restrictions.
Generate a token per session: $_SESSION['csrf'] = bin2hex(random_bytes(32));. Embed it in forms: <input type="hidden" name="csrf_token" value="<?= $_SESSION['csrf'] ?>">. On form submission, verify: hash_equals($_SESSION['csrf'], $_POST['csrf_token']). Always use hash_equals() to prevent timing attacks.
No. The tokens are generated server-side on each request and returned to your browser. They are not logged, stored in a database, or transmitted anywhere except back to you in the API response. The server processes the request and immediately discards the values.
Yes — the same cryptographic randomness that makes a good CSRF token also makes a good password reset token. Use at least 32 bytes in hex or Base64URL format, store the token (or its hash) in your database with an expiry timestamp, and invalidate it after one use.
Cross-Site Request Forgery (CSRF) is a class of web security vulnerability where an attacker tricks an authenticated user's browser into sending an unintended HTTP request to a web application. Because the browser automatically attaches cookies (including session cookies) to every request, the server cannot distinguish a legitimate form submission from a forged one — unless an additional secret is verified.
A CSRF token solves this by embedding a unique, unpredictable value in each form or request. The server verifies that the submitted token matches the one stored in the user's session. A forged request from a third-party site cannot include this value, because it is hidden from external scripts by the browser's Same-Origin Policy.
💡 Looking for premium web development assets? MonsterONE offers unlimited downloads of templates, UI kits, and scripts — worth checking out.
This tool uses PHP's built-in random_bytes(int $length) function, available since PHP 7.0. Unlike rand() or mt_rand(), which use deterministic algorithms seeded by predictable values, random_bytes() requests entropy directly from the operating system:
/dev/urandom or uses the getrandom() syscallCryptGenRandom via the Windows CNG APIThe result is a byte string that is computationally indistinguishable from true randomness, making it suitable for security-sensitive values such as CSRF tokens, password reset links, API nonces, and session secrets.
The raw output of random_bytes() is binary, so it must be encoded before use in HTML or HTTP. The right choice depends on your context:
bin2hex()) — doubles the byte length (32 bytes → 64 hex characters). Only uses [0-9a-f], making it universally safe in HTML attributes, JSON, and query strings. This is the most common choice for server-side frameworks.base64_encode()) — more compact (32 bytes → 44 characters) but includes +, /, and =, which need percent-encoding in URLs.+ with - and / with _, and strips padding. The best choice for tokens embedded in URLs or JSON payloads.Here is a complete, minimal CSRF implementation in PHP:
// 1. Generate and store the token in session (once per session or per form)
session_start();
if (empty($_SESSION['csrf_token'])) {
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}
// 2. Embed in HTML form
echo '<input type="hidden" name="csrf_token" value="' . htmlspecialchars($_SESSION['csrf_token']) . '">';
// 3. Validate on form submission (use hash_equals to prevent timing attacks)
if (!isset($_POST['csrf_token']) || !hash_equals($_SESSION['csrf_token'], $_POST['csrf_token'])) {
http_response_code(403);
die('CSRF validation failed');
}
// 4. Optionally regenerate after use (for one-time tokens)
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));Modern browsers support the SameSite cookie attribute (Strict or Lax), which provides a layer of CSRF defense by restricting when cookies are sent on cross-origin requests. However, CSRF tokens remain the recommended defense because:
SameSiteSameSite=Lax still allows cookies on top-level GET navigationsSameSite protectionsUse CSRF tokens AND set SameSite=Strict or SameSite=Lax on your session cookies for layered protection.
=== — use hash_equals() to prevent timing side-channel attacks that can leak token values character by character.X-CSRF-Token HTTP header for AJAX.SPAs and fetch-based applications typically use the X-CSRF-Token (or X-Requested-With) request header pattern. The flow is: serve the CSRF token in a cookie or a meta tag, read it with JavaScript, and attach it as a custom header on every state-changing request. Since CORS prevents cross-origin JavaScript from reading cookies or custom headers, the server can validate the header as proof of same-origin intent.