report-uri vs report-to vs Reporting-Endpoints: which CSP reporting setup should you use in 2026?

CSP violation reporting suffers from a naming disaster: a deprecated directive (report-uri), a current directive (report-to), a deprecated header that looks exactly like the current directive (Report-To), and the header that actually replaced it (Reporting-Endpoints). Four names, two generations, one job.

Here’s the setup to deploy in 2026, and then the explanation of each piece:

Reporting-Endpoints: csp-endpoint="https://report.example.com/endpoint"
Content-Security-Policy: default-src 'self';
  report-uri https://report.example.com/endpoint;
  report-to csp-endpoint

Both reporting directives, one endpoint declaration. Browsers that understand report-to use it and ignore report-uri. Everything older falls back to report-uri. No browser reports twice. This belt-and-suspenders combination is what CentralCSP’s endpoint accepts natively, all three mechanisms on one URL, precisely because the transition is nowhere near finished.

(Different question: if you searched “report uri” looking for the reporting service by that name, that’s Report URI, Scott Helme’s product. We compare it with CentralCSP in a dedicated article.)

The four names, untangled

report-uri (directive, CSP Level 2). The original. Takes a URL directly, fires a POST per violation, immediately. Deprecated in the spec for years, still honored by every browser in circulation. Its report is a single JSON object under a csp-report key, kebab-case fields (blocked-uri, violated-directive), content type application/csp-report.

report-to (directive, CSP Level 3). The replacement. Takes an endpoint name, not a URL, and relies on a separate header to resolve that name. Reports travel through the Reporting API: batched, delivered asynchronously (sometimes minutes later), camelCase fields (blockedURL, effectiveDirective) inside a wrapper carrying age, type, url and user_agent, content type application/reports+json.

Report-To (header, Reporting API v0). Deprecated. Declared endpoints as a JSON blob. Its lowercase near-twin being a current directive has confused a generation of engineers and at least one security vendor’s documentation. If your config sets it, migrate.

Reporting-Endpoints (header, Reporting API v1). Current. One line, name-to-URL mappings, quoted HTTPS URLs only:

Reporting-Endpoints: csp-endpoint="https://report.example.com/endpoint", default="https://report.example.com/other"

It also carries every other Reporting API report type (deprecation, crash, COOP violations), which is why the names matter: one header can feed several streams to several endpoints.

What changed in 2026

Support, finally. Reporting-Endpoints reached cross-browser baseline in September 2024. The report-to directive followed and, per MDN’s compatibility data, has been baseline across the latest browser versions since March 2026.

Read that carefully though: “latest versions”. Enterprise fleets pinned to older browsers, embedded WebViews, and the long tail of unupdated devices still speak only report-uri. Dropping the legacy directive today means going blind on exactly the clients most likely to be running outdated, vulnerable software. Our recommendation stands until your own user-agent data says otherwise: ship both directives, let each browser pick.

The differences that actually bite

Two of these rows cause most real-world confusion. The batching means “I deployed report-to and nothing arrives” is often just impatience, and it makes the Reporting API a poor fit for real-time incident detection on its own. And the HTTPS-only rule fails silently: an http:// endpoint in Reporting-Endpoints produces no error, no warning, and no reports, ever.

The format split also means a homegrown collector needs two parsers and a content-type switch. Managed endpoints absorb this. CentralCSP normalizes both formats into one indexed stream, so a violation looks the same in your dashboard whether it arrived from a 2019 browser or yesterday’s Chrome. The same endpoint takes the other Reporting API types too (NEL, crash, deprecation, COOP, COEP: 12 in all) if you decide to route them there. The reporting setup docs cover the exact header lines.

Migration checklist

1. Add Reporting-Endpoints with a named HTTPS endpoint.
2. Add report-to <name> to your CSP, keeping the existing report-uri line.
3. Delete any Report-To header (capital T) left over from Reporting API v0.
4. Confirm your collector handles application/reports+json and its batched arrays.
5. Revisit dropping report-uri when your traffic stats say legacy clients are gone. For most sites, that day is years away.

The naming mess is permanent. The setup, at least, doesn’t have to be complicated.