Real headers. Real experiments.

Set HTTP response headers in Project settings. They are served by the preview HTTP server, not simulated with meta tags.

Presets are just a starting point

Choose Default, Allow all CORS, Cross-origin isolated, Strict CSP, or Embeddable. Every preset produces editable header rows. Publish a version to preserve the header configuration alongside the source and JavaScript mode.

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Access-Control-Allow-Origin: *

Inspect the actual response

curl -I http://127.0.0.1:3002/render/YOUR_SLUG/latest

The preview has a security boundary

The runtime runs on a separate origin and always supplies an independent Content-Security-Policy sandbox. Arbitrary source never runs on the editor origin. Service workers, nested frames, and objects are disabled. User CSP is added as a separate policy, so it cannot relax the platform sandbox. Source resources are served with CORS support for ES modules.

Cross-origin isolation has browser constraints

COOP applies to top-level documents. A sandboxed iframe in a non-isolated editor may not expose SharedArrayBuffer even when its response has COOP and COEP. Use the standalone preview and inspect its environment. The platform’s mandatory sandbox may still constrain browser APIs. Restrictive CSP can intentionally block source resources and the diagnostic script; “Not reported” does not imply success.

Reserved headers

Set-Cookie, Clear-Site-Data, Strict-Transport-Security, Location, Refresh, authentication, service-worker scope, reporting, and transport/content framing headers are reserved. Values containing control characters, duplicate names, oversized values, and malformed names are rejected server-side. All other valid header names can be entered manually.