# Report-To vs Reporting-Endpoints (/en/docs/web-security/reporting-api/concepts/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](/en/docs/web-security/policies/network-error-logging), which still requires `Report-To`.

## The two generations [#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.

<CodeBlockTabs defaultValue="Report-To (v0)">
  <CodeBlockTabsList>
    <CodeBlockTabsTrigger value="Report-To (v0)">
      Report-To (v0)
    </CodeBlockTabsTrigger>
  </CodeBlockTabsList>

  <CodeBlockTab value="Report-To (v0)">
    ```http
    Report-To: { "group": "csp-endpoint", "max_age": 10886400,
                 "endpoints": [ { "url": "https://<Endpoint-ID>.report.centralcsp.com" } ] }
    ```
  </CodeBlockTab>
</CodeBlockTabs>

`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.

<CodeBlockTabs defaultValue="Reporting-Endpoints (v1)">
  <CodeBlockTabsList>
    <CodeBlockTabsTrigger value="Reporting-Endpoints (v1)">
      Reporting-Endpoints (v1)
    </CodeBlockTabsTrigger>
  </CodeBlockTabsList>

  <CodeBlockTab value="Reporting-Endpoints (v1)">
    ```http
    Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"
    ```
  </CodeBlockTab>
</CodeBlockTabs>

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 [#what-changed-and-why]

| Aspect        | `Report-To` (v0)                  | `Reporting-Endpoints` (v1)   |
| ------------- | --------------------------------- | ---------------------------- |
| Syntax        | JSON groups                       | `name="url"` pairs           |
| URLs per name | Several, with priority and weight | One                          |
| Caching       | `max_age`, ambient across pages   | None, per-response           |
| Subdomains    | `include_subdomains`              | Not applicable               |
| Scope         | Cached for the origin             | The response it is served on |
| Standard      | Non-standard, deprecated          | W3C Reporting API            |
| Support       | Chromium only                     | Widely supported             |

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 [#the-four-way-report-to-confusion]

<Callout type="info">
  "report-to" means different things depending on context. Keep them straight: the `Report-To` header (v0), the `Reporting-Endpoints` header (v1, the modern replacement), the CSP `report-to` directive (names an endpoint from a policy), and the `report-to=` parameter on COOP/COEP/Permissions-Policy headers.
</Callout>

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 [#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](/en/blog/report-uri-vs-report-to).

## FAQ [#faq]

### Is Report-To deprecated? [#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? [#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? [#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 [#see-also]

* [Reporting-Endpoints header](/en/docs/web-security/reporting-api/headers/reporting-endpoints)
* [Report-To header](/en/docs/web-security/reporting-api/headers/report-to)
* [Network Error Logging (NEL)](/en/docs/web-security/policies/network-error-logging)
* [Report-To vs Reporting-Endpoints, which to use](/en/blog/report-to-vs-reporting-endpoints)

## Sources [#sources]

* [Chrome, migrate to Reporting API v1](https://developer.chrome.com/blog/reporting-api-migration)
* [MDN, Reporting-Endpoints header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Reporting-Endpoints)
* [MDN, Report-To header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Report-To)