All tools

package.json Dependency Range Auditor

Code

Parse a package.json's dependencies, devDependencies, peerDependencies, and optionalDependencies fields and classify each version specifier's range type, flagging wildcard ranges, the "latest" tag, git/URL/file/link dependencies, and packages listed with conflicting ranges across sections

Paste a package.json and get every dependency's version specifier classified by range type: exact pin, caret, tilde, comparator range, wildcard, npm dist-tag, git URL, tarball URL, or local file/link path. It flags the risky patterns that are easy to miss in a long dependency list: a wildcard or empty range that accepts literally any version, the non-reproducible "latest" tag, dependencies pulled from git or a URL instead of the registry, and a package listed in more than one section (dependencies, devDependencies, peerDependencies, optionalDependencies) with either a conflicting or a redundant range. This is a structural check on the specifiers themselves, not a live registry lookup or vulnerability scan.

package-jsonnpmdependenciessemvernode

How to use package.json Dependency Range Auditor

  • 1.Paste your full package.json contents.
  • 2.Review the per-dependency table: its section, range type, and any flagged issues.
  • 3.Check the duplicates list for any package listed in more than one section, and fix conflicting ranges first since those are the most likely to cause install-time surprises.

Frequently asked questions

Does this check for known vulnerabilities in my dependencies?
No, it only looks at how each version is specified: how loose the range is and where it resolves from. For actual vulnerability scanning, use npm audit or a dedicated security tool.
Why is a caret range not flagged as an issue?
A caret range like ^1.2.3 is npm's own recommended default: it allows non-breaking updates under semver while still pinning the major version, so it isn't flagged unless it resolves to something riskier like a wildcard or a tag.
What counts as a conflicting duplicate?
The same package name appearing in two different sections (for example dependencies and devDependencies) with two different version ranges. That's flagged as an error since npm has to pick one and the result depends on install order and hoisting rules you may not control.
Does it verify the versions actually exist on npm?
No, it's a structural parse of the specifiers as written in the file. It doesn't make any network request to the npm registry to check whether a given version or package name is real.

Use via API, SDK, or MCP

cURL# Free: 1,000 req/day · Pro: 10,000 req/day
curl -X POST https://api.utilix.tech/v1/tools/package-json-dependency-auditor \
  -H "Authorization: Bearer utx_live_..." \
  -H "Content-Type: application/json" \
  -d '{"text":"{\n  \"name\": \"pkg\",\n  \"dependencies\": {\n    \"lodash\": \"^4.17.21\",\n    \"left-pad\": \"*\"\n  },\n  \"devDependencies\": {\n    \"lodash\": \"~4.0.0\"\n  }\n}\n"}'

Get an API key from your dashboard · Full API docs →

Related tools

package.json "exports" Field ValidatorParse a package.json's exports map and flag common dual-package (ESM/CJS) misconfigurations: a types condition not listed first, a missing default fallback, mismatched require/import extensions, mixed subpath and condition keys, and a subpath pattern with no matching *CodeConventional Commit Message LinterLint a git commit message against the Conventional Commits v1.0.0 spec: header format, blank-line separation, footer tokens, and BREAKING CHANGE casingCodeSemver CalculatorParse, compare, and check semantic version rangesCode