Dependency Vulnerability Scanner

A real vulnerability scan, right in the browser

Most "online npm audit" tools ask you to upload your whole project or paste in code. This one does not. It hand-parses your lockfile locally — npm's package-lock.json (v1 through v3), classic yarn.lock, or a plain package.json — and extracts the deduplicated list of exact name@version pairs. Those pairs, and nothing else, are batched to the OSV.dev query API. OSV is the open-source vulnerability database maintained by Google's security team; it aggregates the GitHub Advisory Database, the npm advisory feed, and more, so the results map to the same GHSA and CVE identifiers you would see from npm audit.

The report is built like a proper audit, not a raw JSON dump. A headline card shows the total number of vulnerabilities, a breakdown by severity, and how many of your packages are affected, with a one-line posture summary ("3 critical issues found" or "No known vulnerabilities found"). Below it, findings are grouped by package and sorted worst-first, so the things that need attention float to the top. Each finding carries its CVSS-derived severity, the advisory ID, a plain summary, a recommended upgrade to X fixed version when OSV publishes one, and links straight to the source advisories.

How to use this tool

1. Upload or paste your package-lock.json, yarn.lock, or package.json.
2. Confirm the detected lockfile type and the package count it found.
3. Click Scan for vulnerabilities — only name@version pairs are sent to OSV.dev.
4. Read the scored report and note the recommended fix versions.
5. Upgrade the flagged packages and re-scan to confirm a clean tree.

Good to know

• Severity uses the standard CVSS v3.1 scale, computed in your browser from the published vector when no qualitative rating is provided.
• Scanning a package.json gives approximate results because it stores version ranges, not resolved versions — the report flags this clearly.
• Large lockfiles are batched into chunks so even a deep dependency tree scans cleanly.
• Need to format or inspect the lockfile first? Try the JSON Formatter to prettify package-lock.json, and use the JWT Decoder for another browser-side security utility.

Frequently asked questions

Is my code or lockfile uploaded anywhere?

No. Your lockfile is parsed entirely in your browser — the file itself, its full contents, and your source code never leave your machine. To check for vulnerabilities, the tool sends only the package name and version pairs (for example "[email protected]") to the OSV.dev API, operated by Google's open-source security team. Nothing else is transmitted. This is the one piece of data that must leave the browser to perform a real lookup, and we are upfront about it.

What files can I scan?

You can scan a package-lock.json (npm v1, v2, or v3), a yarn.lock (classic v1 format), or a package.json. The first two contain exact resolved versions, so results are precise. A package.json only lists version ranges (like ^4.17.0), so those results are approximate — we strip the range prefix to a best-effort exact version and clearly flag the report as approximate. For accurate results, prefer your lockfile.

Where does the vulnerability data come from?

All advisories come from OSV.dev, an open, free vulnerability database that aggregates data from the GitHub Advisory Database, npm, and other sources. Each finding links back to its original GHSA or CVE advisory so you can read the full details and confirm the fix yourself.

Does this replace npm audit?

It complements it. npm audit runs locally against your installed tree and requires a Node project on disk. This tool needs no install and no project checkout — you can scan a lockfile from anywhere, including one a teammate pasted to you, and only the name@version pairs leave your browser. Both ultimately draw on overlapping advisory data, so use whichever is convenient; treat any reported vulnerability as worth investigating.

What do the severity levels mean?

Severities follow the CVSS v3.1 scale. Critical (9.0–10.0) and High (7.0–8.9) issues usually warrant an immediate upgrade. Medium (4.0–6.9) issues should be planned in. Low (0.1–3.9) issues are often low-risk in practice but still worth tracking. When an advisory ships an explicit qualitative severity we use it; otherwise we compute the score from the published CVSS vector in your browser.