CSP Header Generator

Build Content-Security-Policy headers visually. Select directives, pick values, and export as an HTTP header or HTML meta tag.

About This Tool

The CSP Header Generator is a free, browser-based tool that helps developers construct Content-Security-Policy (CSP) headers without memorizing the specification. CSP is one of the most powerful HTTP security headers available today — it tells the browser exactly which sources of content (scripts, stylesheets, images, fonts, frames, and more) are permitted to load on a page. A well-configured policy is the single most effective defense against cross-site scripting (XSS) attacks, click-jacking, and data-injection vulnerabilities.

Despite its importance, writing a CSP header by hand is error-prone. A single typo in a directive name, a missing quote around 'self', or a forgotten semicolon can break the entire policy — or worse, silently weaken it. This tool eliminates those risks by providing checkboxes for every common source value and dedicated text fields for custom domains. As you toggle options, the complete header string and the equivalent HTML <meta> tag are regenerated in real time, ready to copy.

The generator covers thirteen directives that appear in most production policies: default-src, script-src, style-src, img-src, font-src, connect-src, media-src, object-src, frame-src, base-uri, form-action, frame-ancestors, and report-uri. Two one-click presets — Strict and Permissive — give you a sensible starting point that you can customize to match your exact requirements.

All processing happens entirely in your browser using client-side JavaScript. No data is sent to any server, so you can safely configure policies that reference internal or staging domains. Once your policy is ready, test it alongside your other security headers with the HTTP Header Analyzer, or generate the accompanying <meta> tags with the Meta Tag Generator. If you need to compose the complete set of server response headers, the Nginx Config Generator can help you integrate CSP into your web-server configuration.

How to Use

  1. Click Strict Preset or Permissive Preset for a quick starting point, or begin from scratch by enabling individual directives with their checkboxes.
  2. For each enabled directive, click the source-value chips ('self', 'none', https:, etc.) to toggle them on or off. Active values are highlighted in blue.
  3. Enter any custom domains (e.g. cdn.example.com, *.googleapis.com) in the text field below the chips. Separate multiple domains with spaces or commas.
  4. Review the generated HTTP Header output on the right. The full Content-Security-Policy: ... string updates in real time.
  5. Switch to the HTML Meta Tag panel if you prefer to deploy CSP via a <meta> element instead of a server header.
  6. Click Copy Header or Copy Meta Tag (or press Ctrl+Shift+C) to copy the output to your clipboard.
  7. Use the Clear button to reset all directives and start over.

FAQ

What is Content-Security-Policy (CSP)?

Content-Security-Policy is an HTTP response header that tells the browser which sources of content — scripts, styles, images, fonts, frames, and more — are allowed to load on a page. By restricting sources to a trusted allow-list, CSP prevents attackers from injecting malicious scripts or content, making it the most effective header-level defense against cross-site scripting (XSS) attacks.

What is the difference between an HTTP header and a meta tag?

Both deliver the same policy to the browser. The HTTP header (Content-Security-Policy: ...) is set by the web server in its response, while the HTML meta tag (<meta http-equiv="Content-Security-Policy" content="...">) is embedded in the page's <head>. The header method is preferred because it applies before any HTML is parsed, and some directives like frame-ancestors and report-uri are only supported via the header, not the meta tag.

What does 'self' mean in a CSP directive?

'self' refers to the current origin — the same scheme, host, and port as the document itself. For example, if your page is served from https://example.com, 'self' allows resources from https://example.com but blocks resources from https://cdn.example.com or http://example.com (different scheme). It is the most common starting value for most directives.

When should I use the Strict preset vs. the Permissive preset?

The Strict preset blocks all external sources and disallows inline scripts and eval. It is ideal for security-focused applications where you control every resource. The Permissive preset allows HTTPS sources, inline styles, and eval — suitable as a temporary policy while you audit which external resources your site actually needs. Start strict and relax selectively.

Why is 'unsafe-inline' considered risky?

'unsafe-inline' allows inline <script> and <style> tags, onclick handlers, and style attributes to execute. This effectively disables CSP's XSS protection for that resource type, because an attacker who can inject HTML can also inject inline scripts. Where possible, move scripts to external files and use nonces or hashes instead of 'unsafe-inline'.

Is my data safe?

Yes. All policy generation happens entirely in your browser using client-side JavaScript. No data — including domain names, directive selections, or the generated header — is ever transmitted to a server. You can safely configure policies that reference internal, staging, or production domains without any privacy concerns.

How do I test my CSP policy after deploying it?

Deploy the header with Content-Security-Policy-Report-Only instead of Content-Security-Policy to monitor violations without blocking resources. Add a report-uri or report-to directive to collect violation reports. Once you are confident no legitimate resources are blocked, switch to the enforcing Content-Security-Policy header. Browser DevTools (Console tab) also show CSP violations in real time.

Related Tools