Manifest audit
Paste package.json, composer.json, requirements.txt, or pyproject.toml to review allowed ranges and spot outdated dependencies before you update anything.
Dependency Version Checker & Lockfile Audit
Audit package.json, composer.json, requirements.txt, package-lock.json, and composer.lock to find outdated dependencies, known vulnerabilities, and risky upgrades.
Use this as a package.json audit, composer.json audit, or lockfile audit
Use this page when you want a fast browser-side dependency review before running npm update, composer update, or a broader dependency cleanup.
Paste only a manifest to review allowed ranges, or add package-lock.json / composer.lock to inspect the exact installed versions that shipped.
If you need deploy-to-deploy snapshot comparison after a release, pair this page with Lockfile Diff .
Lockfile audit
Add package-lock.json or composer.lock to switch from manifest minimums to the exact installed versions that actually shipped.
Dependency update planning
Review semver-major jumps, vulnerability fixes, release freshness, and changelog risk before running npm update, composer update, or pip-audit.
Dependency audit FAQ
Can I use this as a package.json audit?
Yes. Paste package.json and optionally package-lock.json to compare declared ranges with the exact installed versions, then review outdated packages, vulnerabilities, and risky upgrades in one pass.
Can I audit composer.json and composer.lock here?
Yes. The page understands composer.json manifests, composer.lock snapshots, Packagist versions, and semver-style constraints so you can triage PHP dependency updates without leaving the browser.
Does this replace npm audit or composer audit?
No. Use it before or alongside npm audit or composer audit. This tool is strongest for dependency update planning, exact-versus-allowed version visibility, semver risk review, and changelog context.
What is semver?
A quick visual reference — everything you need to know to read and write version numbers confidently.
Major
Breaking changes. Existing code may break after upgrading. Read the changelog carefully.
1.x.x → 2.0.0
Minor
New features added in a backwards-compatible way. Safe to upgrade, nothing removed.
2.13.x → 2.14.0
Patch
Bug fixes only. Safe to always update. No new features, no removals.
2.14.0 → 2.14.1
Constraint cheatsheet
| Symbol | Means | Allows | Blocks |
|---|---|---|---|
^1.2.3 | Compatible | minor + patch | major |
~1.2.3 | Approximately | patch only | minor + major |
>=1.2.0 | At least | everything above | nothing |
1.2.3 | Exact | nothing | all updates |
* | Any | everything | nothing |
npm vs Composer — where they differ
~1.2npm
>=1.2.0 <1.3.0Composer
>=1.2.0 <2.0.0Tilde with only major.minor locks minor in npm but allows minor bumps in Composer.
^0.x.ynpm
>=0.x.y <0.(x+1).0Composer
>=0.x.y <0.(x+1).0Both treat 0.x as unstable — minor is treated like major.
Pre-releases & metadata
1.0.0-alpha.1Alpha
Early preview, unstable API. Not ready for production.
1.0.0-beta.2Beta
Feature-complete but may have bugs. API may still change.
1.0.0-rc.1Release Candidate
Near-final. Should be stable unless issues found.
1.0.0+build.42Build metadata
Ignored for comparisons. Two versions differing only here are equal.
Precedence rules
- 1Compare left to right: major first, then minor, then patch.
- 2Pre-release versions rank lower than the release: 1.0.0-alpha < 1.0.0.
- 3Pre-release identifiers are compared dot-by-dot: alpha < beta < rc.
- 4Numeric identifiers sort numerically; text identifiers sort lexically.
- 5Build metadata (+build) is ignored for all comparisons.