Free CSP Header Generator

The CSP Generator is a free online tool that creates Content Security Policy headers to protect your website against XSS, clickjacking, and other injection attacks.

Yes, it is completely free with no registration required. All policy generation happens client-side in your browser.

A CSP tells browsers which content sources are trusted, blocking malicious scripts and reducing the risk of cross-site scripting (XSS) attacks on your website.

Absolutely. The CSP Header Generator processes everything client-side in your browser. No data is uploaded to or stored on any server. Your content remains private on your device at all times.

Yes, the CSP Header Generator is fully responsive and works on smartphones and tablets. You can use it on any device with a modern web browser -- no app download required.

No account or registration is needed. Simply open the CSP Header Generator in your browser and start using it immediately. There are no sign-up walls or usage restrictions.

Simply enter your input in the provided field, adjust any settings to your preference, and the tool will process it instantly. You can then copy the result to your clipboard or download it.

The CSP Header Generator works in all modern browsers including Chrome, Firefox, Safari, Edge, and Opera. For the best experience, use the latest version of your preferred browser.

These are CSP source keywords that tell the browser which content a directive permits. 'self' allows resources only from your own origin (same scheme, host, and port), so a script-src of 'self' loads your own scripts but blocks third-party ones. 'none' is the strictest value: it blocks every source for that directive, which is why object-src 'none' is a common hardening step. 'unsafe-inline' re-enables inline scripts and styles written directly in your HTML, and 'unsafe-eval' permits eval()-based code; both are convenient but reopen the exact XSS hole CSP exists to close, so use a nonce or hash instead where possible. This generator lets you click these keywords directly onto each directive and shows how every choice moves your strictness score, so you can see the security trade-off as you build.

Some directives are simply ignored when a CSP is delivered through an HTML meta tag instead of a real HTTP response header. The frame-ancestors directive, which prevents clickjacking by controlling who can embed your page, only works as a header because the framing decision happens before the document parses the meta tag. The report-uri directive for collecting violation reports and the sandbox directive are ignored in meta form for the same reason. So if your anti-clickjacking or reporting rules seem to do nothing, that is usually why. Wherever you control your server configuration, prefer the HTTP header. This tool flags exactly this limitation in its Output view and gives you the raw Content-Security-Policy header alongside ready-to-paste Nginx, Apache, Express.js, and Next.js config blocks so you can deploy it the correct way.

A nonce is a random, single-use token that lets you trust one specific inline script without opening the door with 'unsafe-inline'. You add the value 'nonce-{random}' to your script-src directive, then put the matching nonce attribute on the script tag you want to allow, like <script nonce="{random}">. The browser runs only inline scripts carrying that exact token and blocks every other injected one, so an attacker who cannot guess the value cannot execute their payload. The critical rule is that the nonce must be freshly generated on every page load, never hard-coded or reused. This generator creates a cryptographically strong nonce with the browser's crypto.getRandomValues() API and gives you the formatted 'nonce-...' string to copy into both your policy and your script tags.

A too-strict policy silently blocks legitimate scripts, styles, or API calls, so shipping CSP straight to enforcement is risky. Report-only mode solves this. By sending the policy under the Content-Security-Policy-Report-Only header instead of Content-Security-Policy, the browser does not block anything; it only logs each violation it would have caused, sending the details to your report-uri endpoint. This lets you watch real traffic, discover which resources trip the policy, and fix the rules before any user sees a broken page. The standard safe rollout is to deploy in report-only first, monitor until the reports go quiet, then switch to the enforcing header. Use this tool's builder to assemble and tune the policy and its Test view to check specific URLs against your directives before you commit to enforcement.

Picking a sensible baseline is faster and safer than building from scratch, and the right starting point depends on your stack. The WordPress preset is more permissive because themes and plugins frequently inject inline scripts and styles, so it allows 'unsafe-inline' and common embed sources like YouTube and Vimeo to avoid breaking the dashboard and front end. The SPA preset suits React, Vue, or Angular builds: it keeps script-src tight at 'self', adds worker-src for blob workers, and opens connect-src for your API and WebSocket endpoints. There are also Strict, Moderate, and Relaxed presets covering the full lockdown-to-lenient range. Apply the closest preset in this tool, then trim or extend individual directives for your real third-party domains while the live strictness score guides you toward a harder policy.