External Resource Inventory
Inventory every script, stylesheet, font, frame, image and connection hint a page pulls in, split by first and third party, and export it as CSV or JSON.
Passive public checka2z.tools reads publicly visible information from the address you enter. It is a read-only request - nothing is submitted, changed or probed.
Use the tool
What a page actually pulls in
Scripts, stylesheets, fonts, images, frames, media and connection hints - from every origin, split by first and third party. Most teams are surprised by the count, which is the reason to produce one.
An inventory is the thing you need before any of the other questions can be answered. You cannot decide whether a third party is worth its risk, write a Content Security Policy that is not either broken or useless, or answer a privacy question about who receives visitor data, without first knowing what is on the list.
First and third party are judged by registrable domain
cdn.example.com is first party to example.com.
example.com.cdn.net is not - and a naive suffix check gets that exactly backwards,
which is also how allow-list bypasses happen. This tool resolves the registrable domain using the
Public Suffix List, so something.co.uk is handled correctly too.
Why connection hints are listed
preconnect and dns-prefetch tell the browser to reach an origin early,
before anything is actually requested from it. They are a performance feature, and they are also a
list of the third parties a page expects. A hint left behind for a vendor you stopped using is
harmless but tells visitors' browsers to contact that vendor on every page load, which is a free
cleanup and occasionally a privacy answer.
Frames are safer than scripts, and not free
An embedded frame runs in its own origin and cannot read your DOM, which makes it a much better way to embed third-party content than a script. It can still request permissions, take up the page, and observe that the visitor is here. Pair frames with a sandbox attribute limiting them to what they need - see Iframe Sandbox Policy Builder.
What this cannot see
The same boundary as every passive tool here: it parses HTML and does not execute the page. Resources loaded by script at runtime are invisible to it. If you need the complete picture, a browser's own network panel or a HAR capture is the right instrument - HAR File Viewer reads one of those.
Export the inventory as CSV or JSON to diff it against a previous run. A new origin appearing without anyone deciding to add it is exactly the event worth catching.
Frequently asked questions
Why does the count differ from my browser DevTools?
DevTools shows what the page actually loaded, including everything injected by script after load. This parses the HTML only. The difference between the two numbers is itself informative - it is the size of your runtime-loaded surface.
How is first versus third party decided?
By registrable domain via the Public Suffix List, not by string matching. A subdomain of your site is first party; a host that merely contains your domain name is not.
Can I use this to build a CSP?
It is the right starting point - it gives you the origins to allow. Do not stop there, because runtime-injected resources will not be in this list. Deploy the policy report-only and use CSP Report Analyzer to find the rest.
Does it follow the resources it finds?
No. It lists what the markup references. It does not fetch each resource, except in the source map checker, which is a separate tool.
References
Related tools
Other Tools
Popular tools from across A2Z
Rate this tool
Was this tool useful? Your feedback helps us improve it.