Website Dependency Inventory

Consolidate the client-side dependencies a site actually loads into one inventory with origins, versions where they can be proven, and an honest uncertainty label on the rest.

Passive public check

a2z.tools reads publicly visible information from the address you enter. It is a read-only request - nothing is submitted, changed or probed.

Page address Reads the page HTML and extracts library versions where the URL states one.

An honest client-side inventory

This lists the front-end dependencies a page loads, with a version wherever the URL states one - a file named jquery-3.5.1.min.js, or a path like /npm/[email protected]/.

It is deliberately clear about what that is worth. A version read from a URL is evidence, not proof. A file with a version in its name can contain anything, a CDN can serve something different, and nothing here verifies the bytes. Where the URL states no version, the tool reports unknown and refuses to guess.

Unknown is not safe

This is the part worth insisting on. Most modern sites bundle their front end, so most of what they load has no readable version at all. A tool that reported "no vulnerable dependencies found" for such a site would be making a claim it has no basis for - a webpack bundle can contain a library five years out of date with a published advisory, and no amount of URL inspection will reveal it.

So unversioned files are counted separately and marked unknown, and the tool says plainly that the only reliable answer comes from the build.

What to do instead, for a real answer

Generate a software bill of materials at build time. CycloneDX and SPDX both have plugins for every major bundler and package manager, and the output covers the transitive dependency tree that a page inspection structurally cannot see.

Then read it with SBOM Viewer, validate it with CycloneDX Validator or SPDX Validator, and diff successive builds with SBOM Diff Checker.

Where this inventory is still useful

CDN-loaded libraries are exactly the case it handles well, and they are the ones least likely to appear in your build's SBOM - they are not installed, so the package manager does not know about them.
Finding what you did not know you shipped. A second copy of a library, an old plugin still referenced by one template, a vendor script nobody remembers adding.
Checking integrity coverage alongside the version, since a pinned version with no SRI is still whatever the CDN decides to serve.

Feed the versions it does find into Vulnerable JavaScript Library Checker.

Frequently asked questions

Why is most of my site listed as unknown?

Because it is bundled. A build tool concatenates your dependencies into one file with no version in the name, which is normal and good practice - it just means a passive page inspection cannot read versions out of it.

Does unknown mean there is no problem?

No, and the tool deliberately says so. Unknown means it could not determine the version. A bundle can contain an outdated library with a published advisory and nothing here would reveal it.

How reliable is a version read from a filename?

It is the site telling you what it thinks it serves. Usually right and never verified. Treat it as a strong hint, and confirm from your build if the answer matters.

Why not fetch each file and fingerprint its contents?

Downloading and analysing every script on a visitor-supplied page is a much larger operation, with a much larger failure surface, for an answer that a build-time SBOM gives you properly. The honest boundary is better than a partial imitation.

References

Related tools

What this tool can and cannot tell you. It reports the configuration a site exposes to an ordinary visitor. It does not log in, submit anything, or test for vulnerabilities, so a passing result means the public configuration looked correct at the moment of the check - not that the site 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.