CSRF Token Generator

A random string is the easy half of CSRF protection. The half that breaks in production is everything around it: which cookie attributes to set, whether the browser is allowed to read that cookie back, and what the server compares against when the form arrives. CSRF Token Generator draws the token and then writes out the wiring it needs, matched to the pattern you choose.

Three patterns are offered, because each one stores the token somewhere different. A synchronizer token lives in the server session and issues no cookie of its own. A double-submit cookie is deliberately readable by JavaScript, since the page has to echo the value back. A signed double-submit keeps the bare token in the cookie and appends an HMAC-SHA-256 signature to the submitted copy, which is what stops a compromised subdomain from writing a cookie and a matching form field that agree with each other.

Defaults land on the common safe case: 32 bytes of entropy, Base64URL output, one token per session, cookie csrf_token, field _csrf, and the header X-CSRF-Token. Change any of the three names and every output line below updates with it.

Options: What Each Control Changes

• Protection pattern decides which outputs appear. Choose Synchronizer token and the Set-Cookie line is replaced by a note telling you to store the value against the session record instead.
• Token size offers 16, 24, 32 and 64 bytes. The default 32 bytes is 256 bits, which renders as 43 Base64URL characters or 64 hex characters. The character count is shown under the buttons so you can check it against a database column width before you commit to it.
• Encoding switches between Base64URL and hex. Base64URL is shorter and contains no cookie-hostile characters; hex is twice as long but survives shell quoting and careless log parsing without any escaping.
• Rotation chooses per session or per request. Per request drops Max-Age entirely and disables the lifetime slider, because a token meant to live for one form render has no business outliving the tab.
• Cookie lifetime runs from 0 to 1440 minutes in 15-minute steps. At 0 the Max-Age attribute is omitted, producing a session cookie that dies when the browser closes.

Edge Cases: Parallel Tabs, Subdomains and Name Validation

• Two open tabs are the reason per-session rotation is the default. With per-request tokens, submitting the form in the first tab invalidates the token already rendered into the second, and the user sees a rejection on a form they filled in honestly.
• Cookie names are validated against the RFC 6265 token set. Typing csrf token with a space produces the message “Cookie name must be an RFC 6265 token — no spaces, commas, semicolons or equals signs.” and the Generate button is disabled until you fix it.
• The missing HttpOnly flag is intentional on the double-submit cookie, and the tool says so under the header rather than leaving you to wonder. Scripts on the page must read that cookie for the pattern to function at all.
• The batch slider goes to 10 tokens, but wiring is only shown for the first. The batch exists for seeding test fixtures with distinct values, not for issuing 10 valid tokens to one visitor.

Not a Substitute for Server-Side Verification

• Comparison has to happen on your server, using a constant-time equality check. A naive string comparison that returns early leaks timing information about how many leading characters matched.
• An absent token must be rejected, not treated as empty and matched against an empty cookie. That single mistake defeats the whole mechanism, and no generator can protect you from it.
• The signing secret shown here is disposable. If you leave the field blank a fresh 32-byte secret is generated so you can see the shape of one, but the real secret belongs in your server environment, loaded identically wherever verification runs.
• Pair the token with SameSite cookies. Tokens and cookie policy cover different gaps, and modern guidance treats them as layers rather than alternatives.

Bytes come from crypto.getRandomValues and signatures from the WebCrypto HMAC implementation, both running inside this tab. No value is logged, transmitted or kept after you navigate away.