How to use Custom Headers

Custom headers allow you to configure HTTP response headers for your Framer site, giving you control over security settings and other header-based requirements.

What are Custom Headers?

Custom headers are HTTP response headers sent from the server to the browser when someone visits your site. They control how browsers interact with your website, including security policies and cross-origin resource sharing. Common use cases are headers like X-Frame-Options to prevent clickjacking attacks, Content Security Policies to protect against XSS attacks.

How to Add Custom Headers

On the Framer dashboard, select your domain in the sidebar, and navigate to the Headers tab.

  1. Click the Plus icon on the right

  2. Define the path where the header should apply (e.g., /, /blog/*, /login)

  3. Select the header name (e.g., X-Frame-Options)

  4. Enter the header value (e.g., DENY, SAMEORIGIN)

  5. Click on Add to save your header

  6. Open your project and re-publish

There is a allowlist of supported headers in the UI. The list focuses on headers that are commonly useful and safe to expose, such as security policies and reporting endpoints.

If you need a header that is not listed, you can request it and it can be added to the whitelist, as was done for reporting endpoints.

Path matching

Custom Headers support flexible path matching:

/ applies to the homepage only
/page applies to the exact path
/page/* applies to all pages under /page
/* applies to all pages on your site

Header priority and ordering

You can reorder your custom headers by dragging them in the list. The order determines which header takes precedence when multiple rules match the same path.

Default headers

Framer automatically sets certain default headers for all sites. You can view these in the Headers tab under the "Default" section. Custom headers you add will supplement or override these defaults where applicable.

Localization

Locale expansion is an option that automatically prefixes your path with all enabled locale codes (for example /nl, /de) at publish time so one rule can match every locale.

Note: Automatic Locale expansion only prefixes the path with the country code. It doesn't support localized paths and slugs. If your rule explicitly references a path that is localized, you have to manually add one additional rule for each locale.

Example configurations

Prevent embedding on external sites

Header: X-Frame-Options
Value: DENY
Path: /*

This prevents your site from being embedded in iframes on other domains.

Allow embedding only on same origin

Header: X-Frame-Options
Value: SAMEORIGIN
Path: /*

This allows your site to be embedded in iframes, but only on your own domain.

Working with Multi Site rewrites

When you use custom headers alongside Multi Site rewrites, you configure headers on your main project (the one with the custom domain). You can set headers for any path on your domain, including paths that are rewritten to other locations.

Important: Only custom headers set on your main project are applied to responses. If a path is rewritten to another Framer project or external origin, any custom headers configured on those target projects are not forwarded.

Let's say you have:

  • Project A with domain example.com (your main project)

  • Project B with domain blog-project.com

  • A rewrite rule on Project A: /blog/:slugblog-project.com/blog/:slug

When a visitor accesses example.com/blog/post:

  • Custom headers you set on Project A for /blog/* will be applied

  • Custom headers set on Project B will NOT be forwarded

This applies to both Framer project rewrites and external origin rewrites. Always configure your Custom Headers on the main project where your domain is connected.

Updated