Report-To vs Reporting-Endpoints

There are two generations of the header that declares reporting endpoints. Report-To came first (often called Reporting API v0) and Reporting-Endpoints replaced it (v1). For almost everything you should use Reporting-Endpoints. The one exception is Network Error Logging, which still requires Report-To.

The two generations

Report-To (v0) declares endpoint groups as JSON. A group has a name, a max_age that caches the configuration, an endpoints array that can hold several URLs with priority and weight for failover, and an optional include_subdomains. The cached, ambient model meant a configuration sent on one response could apply to other pages on the origin.

Report-To: { "group": "csp-endpoint", "max_age": 10886400,
             "endpoints": [ { "url": "https://<Endpoint-ID>.report.centralcsp.com" } ] }

Reporting-Endpoints (v1) drops all of that for a structured-field dictionary of name="url" pairs: one URL per name, no groups, no failover, no caching. It is scoped to the response it is served on, so it must be present on every response that can generate a report.

Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

The W3C Reporting specification defines only Reporting-Endpoints; Report-To was a Chromium-era mechanism that never became a standard, which is why it is marked deprecated and non-standard and only ever shipped in Chromium.

What changed and why

The grouping and caching that made v0 flexible are exactly what other browser engines were unwilling to standardize. v1 trades that flexibility for a simple, per-response header, and that simpler model is now widely supported across current browsers.

The four-way report-to confusion

In practice the directive and the parameter only reference a name; one of the two headers has to declare it:

• Reporting-Endpoints: csp-endpoint="https://..." declares the endpoint (v1).
• Report-To: { "group": "csp-endpoint", ... } declares it the old way (v0).
• Content-Security-Policy: ...; report-to csp-endpoint references it from CSP.
• Cross-Origin-Opener-Policy: same-origin; report-to="csp-endpoint" references it from COOP.

Which to use

Default to Reporting-Endpoints for everything: CSP, COOP, COEP, Permissions-Policy, Document-Policy, Integrity-Policy, and the implicit deprecation, intervention, and crash reports. Keep Report-To only on the responses that also send the NEL header, because Network Error Logging is not supported by v1. For CSP specifically, the report-to directive reached Baseline in 2026, so you only need to keep the deprecated report-uri directive as a fallback for very old browsers, see report-uri vs report-to.

FAQ

Is Report-To deprecated?

Yes. Report-To (Reporting API v0) was a Chromium-era mechanism that never became a standard, so it is marked deprecated and non-standard. Reporting-Endpoints (v1) is the modern replacement, defined by the W3C Reporting specification and Baseline across current browsers. Report-To remains only for Network Error Logging, which v1 does not support.

Do I need both Report-To and Reporting-Endpoints?

Only if you use Network Error Logging, which still requires the legacy Report-To header. For everything else, CSP, COOP, COEP, Permissions-Policy, Document-Policy, Integrity-Policy, and the implicit deprecation, intervention, and crash reports, Reporting-Endpoints alone is enough. Keep Report-To only on the responses that also send the NEL header.

report-to vs report-uri in CSP?

They are different generations of the CSP reporting directive. report-to names an endpoint declared by a Reporting-Endpoints (or Report-To) header and delivers structured Reporting API reports. report-uri is the older directive that takes a URL directly. report-to reached Baseline in 2026; keep report-uri only as a fallback for very old browsers.

See also

• Reporting-Endpoints header
• Report-To header
• Network Error Logging (NEL)
• Report-To vs Reporting-Endpoints, which to use

Sources

• Chrome, migrate to Reporting API v1
• MDN, Reporting-Endpoints header
• MDN, Report-To header