Skip to main content

CSP Generator

Build a Content-Security-Policy header value from structured directive fields (default-src, script-src, style-src, img-src and more) plus a ready-to-paste HTML meta tag.

Input

Fallback source list for directives not explicitly set.

Where scripts may be loaded from.

Where stylesheets may be loaded from.

Where images may be loaded from.

Where fonts may be loaded from.

Origins allowed for fetch/XHR/WebSocket connections.

Where nested browsing contexts (iframes) may be loaded from.

Where <object>/<embed>/<applet> resources may be loaded from.

Where audio/video sources may be loaded from.

Which parents may embed this page in a frame — clickjacking protection.

Restricts URLs usable in a document's <base> element.

Restricts URLs that can be used as an HTML form's action target.

Automatically upgrades the page's HTTP requests to HTTPS.

Output

Generated CSP Header Value

Set this as the value of the Content-Security-Policy response header.

Meta Tag
 
Was this helpful?

Guides

What is a Content-Security-Policy?

Content-Security-Policy (CSP) is an HTTP response header that tells the browser exactly which sources of scripts, styles, images, fonts and other resources a page is allowed to load. It's one of the most effective browser-side defenses against Cross-Site Scripting (XSS): even if an attacker manages to inject a <script> tag into your page through a comment field or unsanitized input, a well-written CSP stops that script from executing (or from being loaded from an attacker's domain in the first place) because it doesn't match any allowed source. CSP also blocks clickjacking (via frame-ancestors), restricts <base> tag injection, and can lock down where forms are allowed to submit to. This tool builds a valid CSP header value from structured directive fields, so you don't have to memorize the syntax or risk a typo that silently disables the policy.

How to use it

  1. Fill in the source list for each directive you want to restrict — for example, default-src with 'self', or script-src with 'self' https://cdn.example.com. Separate multiple sources with spaces.
  2. Leave a directive blank to omit it entirely from the generated header — omitted directives simply fall back to default-src (except frame-ancestors and base-uri, which are never inherited and should be set explicitly).
  3. Enable upgrade-insecure-requests to have the browser automatically rewrite the page's HTTP sub-resource requests to HTTPS.
  4. Copy the Generated CSP Header Value into your Content-Security-Policy response header, or copy the Meta Tag to paste directly into your page's <head>.

Directives supported

  • default-src — fallback source list used by any fetch directive that isn't explicitly set.
  • script-src — where JavaScript may be loaded/executed from.
  • style-src — where CSS may be loaded from.
  • img-src — where images may be loaded from.
  • font-src — where web fonts may be loaded from.
  • connect-src — origins allowed for fetch, XMLHttpRequest, WebSocket and EventSource connections.
  • frame-src — where nested browsing contexts (<iframe>) may be loaded from.
  • object-src — where <object>, <embed> and <applet> resources may be loaded from; 'none' is recommended since these are legacy plugin APIs.
  • media-src — where <audio>/<video> sources may be loaded from.
  • frame-ancestors — which parent origins are allowed to embed this page in a frame; the primary defense against clickjacking.
  • base-uri — restricts the URLs usable in a <base> element, preventing base-tag injection attacks.
  • form-action — restricts the URLs an HTML <form> on the page may submit to.

Common source values

'self' (same origin), 'unsafe-inline' (allows inline <script>/<style> — weakens XSS protection, avoid when possible), 'unsafe-eval' (allows eval() — avoid), a specific domain (https://cdn.example.com), a scheme (https:, data:), or * (any origin — very permissive).

FAQ

Why is my directive missing from the output? Blank directives are omitted entirely — only directives with at least one source are included in the generated header.

Should I use the header or the meta tag? The Content-Security-Policy HTTP response header is preferred — it applies before any HTML is parsed and supports directives (like frame-ancestors and report-uri) that a <meta> tag cannot enforce. Use the meta tag only when you can't control server response headers.

What's the difference between default-src and setting every directive individually? default-src is a fallback: any fetch directive you leave blank inherits it. Setting default-src 'self' alone is a reasonable minimal baseline, but explicit directives give you finer control per resource type.

Privacy

Everything runs in your browser — the directive values you enter are never sent to our servers.

cspcontent security policyhttp headerxssweb securitymeta tagweb development

Love the tools? Lose the ads.

One payment clears every ad from your account, for good. No subscription, no tracking.