Skip to content
TabBench

HTTP Header Generator

Build security headers, CORS headers, Cache-Control and a Content-Security-Policy, then copy them as config for nginx, Apache, Express, Netlify, Vercel and more.

Runs in your browser. Nothing you add is uploaded.

What the HTTP Header Generator does

Correct HTTP headers protect a site and speed it up, but each server wants them in a different format and a single wrong value can break a page. This generator asks for what you want in plain terms (security protections, which site may call your API, how long files may be cached, where scripts may load from) and writes the headers with warnings where an option is risky. It then outputs them as configuration for nginx, Apache, Caddy, Express, Next.js, Netlify, Vercel, Firebase Hosting or IIS, ready to paste.

How to generate HTTP headers for your server

  1. Choose the kind of header: Security, CORS, Caching, CSP or Downloads.
  2. Set the options. Start from a preset where one is offered, such as “Versioned static files” for caching or “Same origin only” for CSP.
  3. Read the warnings under the result. They flag options that commonly break sites, such as includeSubDomains on HSTS or unsafe-inline in a CSP.
  4. Pick your server or host in the format menu and copy the configuration into the file named above the code.
  5. Reload your server, then check the live response with the HTTP Header Analyzer.

The HTTP Header Generator runs entirely in your browser — nothing you enter is uploaded, stored, or logged.

When to use it

Hardening a new site

Generate HSTS, nosniff, framing, referrer and permissions policies in one block and add it to your server configuration before launch, instead of discovering the gaps in a security scan afterwards.

Fixing CORS for an API

Enter the exact origin of your front end, the methods and headers it needs and whether it sends cookies. The generator writes the matching headers, including Vary: Origin, and warns about the wildcard-with-credentials mistake.

Making static assets cache for a year

Use the versioned-files preset to produce Cache-Control: public, max-age=31536000, immutable, so returning visitors never re-download files whose names change with their content.

Good to know

  • Roll out a Content-Security-Policy in report-only mode first and watch for violations before enforcing it.
  • Never cache HTML for a year. Give the HTML no-cache and only the versioned files a long lifetime.
  • HSTS preload is very hard to undo. Test with a short max-age and only preload when every subdomain supports HTTPS.
  • Send CORS headers on the OPTIONS preflight response as well as on the real response.
  • Static-export hosts such as Firebase, Netlify and Vercel read headers from their own config files, not from your application code.

Guides that use this tool

Frequently asked questions

Will these headers break my site?

They can if they are stricter than your site allows, especially Content-Security-Policy and Cross-Origin-Embedder-Policy. Start a CSP in report-only mode, test, then switch it on. The warnings under each result point to the options most likely to cause problems.

Where do I paste the output?

The format menu tells you which file each one belongs in, such as nginx.conf, .htaccess, next.config.js, _headers or firebase.json. After changing server configuration, reload the server.

Do you store the headers I generate?

No. Your choices are kept in your browser for a few days so the tool remembers them, and are never sent anywhere.

What is the difference between no-cache and no-store?

no-cache lets a cache keep the response but forces it to check with the server before each reuse, which is cheap when the file has not changed (a 304). no-store forbids keeping it at all, which is the right choice for private or sensitive pages.

Why does nginx need the word always?

Without it nginx adds add_header lines only to successful responses (2xx and 3xx), so your security headers would be missing from 404 and 500 pages. always adds them to every response.

Does a wildcard in Access-Control-Allow-Origin work with cookies?

No. Browsers reject a response that allows credentials and uses * as the origin. You must name the exact origin and send Vary: Origin.