Security Headers Generator
Choose the protections you want and copy ready-to-paste configuration for your server or hosting platform. The generator covers HSTS, Content-Security-Policy, framing protection, MIME sniffing, the referrer, browser features and cross-origin isolation, explains the effect of every choice, and warns about settings that can break a site or are hard to undo.
- Runs in your browser
- No sign-up
- Free to use
How to use Security Headers Generator
- Start from a preset: Recommended, Strict, Gentle start or JSON API.
- Adjust each header; the notes explain what changes.
- Choose your server or platform under “Output for”.
- Copy or download the configuration, deploy it, and test the live site.
Security Headers Generator features
Eleven headers
HSTS, CSP, X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy, COOP, CORP, COEP and more.
Ten outputs
Apache, Nginx, IIS, Netlify, Vercel, Cloudflare Pages, Express, PHP, raw headers and a meta tag.
Safe presets
A gentle start in report-only mode, a recommended set and a strict set.
Honest warnings
Explains preload risks, CSP side effects and isolation breakage.
Hides server software
Removes X-Powered-By and shortens Server where the platform allows it.
Private
Runs in your browser; nothing about your site is sent anywhere.
When to use Security Headers Generator
- Adding security headers to a new website before launch.
- Fixing the findings of a security scan or penetration test.
- Writing a Netlify or Vercel headers file for a static site.
- Hardening a JSON API so its responses cannot be framed or rendered as pages.
Security Headers Generator FAQ
Which security headers matter most?
Strict-Transport-Security (forces HTTPS), Content-Security-Policy (limits where scripts can come from), X-Frame-Options or frame-ancestors (prevents clickjacking) and X-Content-Type-Options: nosniff. Referrer-Policy and Permissions-Policy are useful privacy additions.
Can these headers break my site?
Yes. Content-Security-Policy can block scripts, styles and fonts you rely on, and HSTS stops plain HTTP from working. That is why the Gentle start preset uses a short HSTS duration and report-only CSP, so you can see what would break before enforcing.
Do I still need X-Frame-Options if I set frame-ancestors?
Modern browsers follow frame-ancestors in CSP. X-Frame-Options is still sent for older browsers and some security scanners; the two are kept consistent here.
Why is X-XSS-Protection off by default?
The XSS filter it controlled has been removed from browsers, and in old browsers it could itself be abused. Current advice is to omit it or send 0 and rely on Content-Security-Policy.
Can I set these headers with HTML meta tags?
Only Content-Security-Policy, and without frame-ancestors, report-uri and sandbox. The other headers have no effect in a meta tag and must be sent by the server.
How do I check that the headers are live?
Open the site, then use the Website Security Checker or HTTP Header Checker on this site, or the Network tab of your browser’s developer tools.
What security headers do
HTTP response headers tell the browser how to treat a page. A handful of them switch on protections that the browser does not apply by default: always using HTTPS, refusing scripts from unexpected places, refusing to be framed by another site, and refusing to guess the type of a file. They cost nothing to send and remove whole classes of attacks, which is why security scanners check for them first.
Strict-Transport-Security tells the browser to use HTTPS for the domain for a set time, even if someone types http:// or follows an old link. Because the browser remembers it, a mistake is remembered too, so it is wise to begin with a few minutes and raise the duration once everything works. The preload flag goes further and asks browser makers to build the rule into the browser itself; removing a domain from that list takes months.
Content-Security-Policy is the most powerful and the most likely to break things. A policy lists where scripts, styles, images, fonts and connections may come from. Injected script from an attacker then fails to run. Sites that use inline scripts, analytics or third-party widgets need those sources listed, or a nonce-based strict policy set by the application. Report-only mode lets you observe what a policy would block without blocking it.
The cross-origin headers deal with newer attack styles. Cross-Origin-Opener-Policy separates your window from pop-ups opened on other sites, Cross-Origin-Resource-Policy decides which sites may load your files, and Cross-Origin-Embedder-Policy is needed only when a page wants full cross-origin isolation. The defaults here avoid the settings that commonly break sign-in pop-ups and embedded media.
Where you set the headers depends on the hosting. Apache reads them from .htaccess or the virtual host, Nginx from the server block, IIS from web.config, and static hosts such as Netlify, Vercel and Cloudflare Pages from a headers file. Application frameworks can set them in code, which is the only place a per-request CSP nonce can be created. Whichever you use, test the live site afterwards, because a proxy or CDN in front of the server can add, change or drop headers.