Use require-corp when you control or can influence every cross-origin resource your page loads, since each one must opt in. Use credentialless when you cannot get third parties to add headers: the browser loads their no-cors resources without cookies instead of blocking them. Both can support cross-origin isolation.
What each value does
Both values apply to cross-origin resources requested in no-cors mode, which is the default for plain image, script and stylesheet tags. Requests made in cors mode follow CORS rules under both values.
| Behaviour | require-corp | credentialless |
|---|---|---|
| Cross-origin no-cors resource with no CORP header | Blocked | Loaded, without credentials |
| Cookies on those requests | Sent as normal if allowed | Omitted in the request, ignored in the response |
| Resource with a permissive CORP header | Loaded | Loaded |
| cors mode resources | Need CORS permission | Need CORS permission |
The MDN wording for credentialless is direct: requests are sent without credentials, so cookies are omitted in the request and ignored in the response.
Why credentialless exists
Under require-corp, the owner of every embedded image, font or widget must send a Cross-Origin-Resource-Policy header that allows your page. For third-party tags and ad networks, that is often out of your hands. credentialless removes that dependency. The reasoning is that a no-credentials request cannot return personalised, private data, so the resource is safe to pull into an isolated process.
The cost is functional. Anything that needs the visitor's cookies to render properly will arrive as the logged-out version. A map tile or avatar that depends on a session may appear blank or generic.
How to choose
- Inventory the cross-origin resources the page loads, split by tag type.
- Mark the ones you own. Add CORP headers there first.
- For third parties, ask whether a logged-out response is acceptable. If yes,
credentiallessremoves the blocker. - If a resource must carry cookies and the vendor will not add CORP, either use cors mode where the vendor supports it, or drop the embed from the isolated page.
- Add
report-toto see what is blocked before you enforce.
Reporting-Endpoints: coep-endpoint="https://reports.example.com/coep"
Cross-Origin-Embedder-Policy: credentialless; report-to="coep-endpoint"
Note that the MDN page states the header should carry only one token. Setting it more than once, or with several tokens, is treated as unsafe-none, so check that a proxy or framework is not adding a second copy.
Remember the other half
Neither value gives isolation alone. MDN lists COOP same-origin as the paired header, and a Permissions-Policy that does not block the feature. If crossOriginIsolated still reads false after you set COEP, look at COOP first.
Quick check
Does credentialless mean my own cookies are dropped?
No. It applies to cross-origin no-cors resource requests your page makes. Your own same-origin requests are unaffected.
Can I just use require-corp and fix things later?
You can, but blocked resources will simply fail to load for users. Run with a report-to endpoint on staging so the failures show up as reports instead of support tickets.
Safeguard produces an SBOM and dependency scan for your front end, a useful starting list when you inventory the scripts and packages that will meet your new embedding policy. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
