CSP Report Analyzer

Load csp-report or Reporting API violation data and group it by directive and source, separate genuine blocks from extension noise, and see which policy changes the evidence actually supports.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Violation reports JSON, a JSON array, JSONL, the legacy csp-report shape or the Reporting API shape. Mixed formats in one paste are fine.

Or drop a report file here

Up to 20 MB. Read in your browser - nothing is uploaded.

What CSP violation reports tell you, and what they do not

When a Content Security Policy blocks something - or would block it, in report-only mode - the browser can send a JSON report to an endpoint you nominate. Those reports are how you find out whether a policy is ready to enforce. Read raw, though, they are misleading in a specific and consistent way, and this tool exists because of that.

Most reports from a public site are not about your site

Browser extensions inject scripts and styles into pages. So do antivirus products, corporate proxies, translation services, writing assistants and accessibility overlays. Every one of those injections violates a strict policy, and every one generates a report that looks exactly like a genuine one until you read the blocked URI.

On a public site this is routinely the majority of the volume. The failure mode is predictable: a team sees thousands of violations, panics, and loosens the policy until they stop - which means adding permissions for software running in other people's browsers, weakening the policy for everyone, and fixing nothing. This tool separates those groups out first and states the proportion explicitly, so the number you act on is the number that is actually about your pages.

How reports are classified here

Extension - the blocked URI uses an extension scheme such as chrome-extension: or moz-extension:. Never your content, never a reason to change the policy.
Page-rewriting software - the blocked host belongs to known antivirus, translation or assistant software that modifies pages in the browser.
Worth acting on - a resource your own page referenced, an inline block, or a call to eval. These are the ones to look at.
Not actionable - the browser reported no usable blocked URI. Browsers redact this in some cross-origin cases, and there is genuinely nothing to decide from it.

Classification is by scheme and by registrable domain, matched as a proper suffix rather than a substring, so avast.com.example.net is not mistaken for avast.com.

Why this tool will not suggest 'unsafe-inline'

Inline and eval violations cannot be fixed by allowing an origin, and the change that would silence them - 'unsafe-inline' or 'unsafe-eval' - removes most of the protection the policy provides. Suggesting it would be telling you to delete the thing you are trying to deploy.

For inline blocks, the answer is a nonce or a hash from CSP Nonce and Hash Generator. For eval, the answer is to find the caller - usually an older template engine, a bundler in development mode, or a date library - and replace it. The tool shows you the script sample the browser sent so you can locate it.

Reading the grouped output

Reports are grouped by directive and blocked origin rather than listed individually, because a single missing CDN produces thousands of identical reports and a list of them tells you nothing a count does not. Each group shows how many reports it produced and how many distinct pages it appeared on. A violation on one page is a specific bug; the same violation on every page is a missing origin.

Suggested additions are offered per directive, and only for origins that were classified as genuinely yours. Add them one at a time and re-measure. A policy that grows until the reports stop is a policy that no longer restricts anything.

Everything is processed in your browser

Violation reports are more sensitive than they look. They carry the full URL of the page that triggered them, which on an authenticated site can include account identifiers, and sometimes tokens in a query string. They also name internal hostnames and staging environments. None of that is uploaded here - the file is read and analysed locally, and the exports are generated in the page.

Frequently asked questions

Which report formats does this accept?

The legacy {"csp-report": {...}} shape, the Reporting API {"type":"csp-violation","body":{...}} shape, and bare body objects. Any of those as a single object, a JSON array, or one per line as JSONL. Field names differ between the formats - blocked-uri versus blockedURL - and both spellings are read.

Why do so many reports have an empty blocked URI?

Browsers deliberately redact it in some cross-origin situations to avoid leaking where a visitor was navigating. It is expected behaviour rather than a fault, and there is nothing actionable in those reports, so they are grouped separately rather than counted as real.

Should I add every origin the reports show?

No. A blocked origin is sometimes the policy working correctly - a tag manager pulling in a vendor nobody approved, for instance. Confirm each origin is something you meant to load before allowing it.

How long should I collect reports before enforcing?

Long enough to cover real traffic patterns. A week is a reasonable minimum because it catches weekly scheduled jobs, weekend traffic and the long tail of unusual browsers. What matters is that new distinct groups have stopped appearing.

Is any of this stored?

No. Parsing, grouping and classification all happen in your browser, and nothing is transmitted or written to storage.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.