The CSP Header Generator is 100% client‑side. Your directives, sources and hosts are just strings joined together on your device by a local engine — there is no server call, no CDN in the processing path, no logging and no telemetry. The optional sample nonce is generated locally with crypto.getRandomValues (never Math.random). The tool works offline once cached, keeps no history, and the only optional network use anywhere on the site is consent‑gated ads, which never see your policy.

‘unsafe-inline’ allows inline <script> blocks, on* event handlers and javascript: URLs to execute — exactly the payloads an XSS attacker injects — so a policy that keeps it barely constrains script execution. The modern fix is a per-response nonce (a random token echoed on each <script nonce>) or a sha256 hash of each trusted inline script, usually combined with ‘strict-dynamic’. Helpfully, all recent browsers IGNORE ‘unsafe-inline’ whenever a nonce or hash is present, so you can keep it purely as a fallback for very old browsers. The tool warns you whenever ‘unsafe-inline’ appears without a nonce or hash.

A <meta http-equiv="Content-Security-Policy"> tag is a convenient fallback when you cannot set response headers, but it is NOT fully equivalent. The frame-ancestors directive (your clickjacking defence), the reporting directives report-uri and report-to, and the sandbox directive are all ignored inside a meta tag — they must be delivered as real HTTP headers. Content-Security-Policy-Report-Only also cannot be delivered via meta. This tool emits the meta form alongside the header and explicitly flags which directives were dropped, so you know what still needs to be a header.

A strict policy will almost always block something on the first try, so start with the Content-Security-Policy-Report-Only header (this tool has a one-click Report-Only mode). In that mode the browser reports violations but does NOT block anything, letting you discover which legitimate scripts, styles or third-party hosts your app really uses. Collect reports via a report-uri endpoint or a report-to group (which needs a matching Reporting-Endpoints response header), add the necessary sources, and once the reports are clean, flip to the enforcing Content-Security-Policy header. Always test against your real site — CSP is defence-in-depth, not a replacement for fixing the underlying injection bug.