A caret such as ^1.5.2 in package.json means "compatible with" that version. npm may install any newer version that keeps the same leftmost non-zero part, so 1.9.0 qualifies but 2.0.0 does not. The range is a permission, not a pin. The lockfile decides what you actually get.
Ranges in one table
The npm package.json documentation lists the common range operators. Here is how the ones a new developer meets first behave.
| Entry | Meaning | Example match |
|---|---|---|
| 1.5.2 | Exactly this version | 1.5.2 only |
| ^1.5.2 | Compatible with 1.5.2 | 1.5.2 up to below 2.0.0 |
| ~1.5.2 | Approximately equivalent | 1.5.x patches |
| 1.5.x | Any patch of 1.5 | 1.5.0, 1.5.1 |
| * | Any version | everything |
The caret is the default npm writes when you add a package, unless you ask for an exact version. The documentation for npm install describes a save-exact flag for that: saved dependencies get an exact version instead of npm's default range operator.
Why this matters for security
A range is a standing invitation. If a maintainer publishes 1.9.0 tomorrow, a fresh install without a lockfile can pick it up. Most of the time that is a bug fix you wanted. Occasionally it is a compromised release. The range cannot tell the difference.
That is why the lockfile exists. The npm documentation says package-lock.json describes the exact tree that was generated, so later installs produce identical trees regardless of intermediate dependency updates. With a committed lockfile, the caret only matters when someone deliberately updates.
What a new developer should do
- Leave the existing ranges alone unless your team has a pin policy.
- Commit package-lock.json with every dependency change, in the same pull request.
- Use npm ci on a fresh clone so the lockfile is honored instead of rewritten.
- When you add a package, read what npm wrote to package.json and ask whether the team prefers exact versions.
- Never use * for a dependency. It removes all control.
There is a real tradeoff between ranges and exact pins. Exact pins give predictability but make you responsible for every update, which is easy to forget. Ranges plus a lockfile plus a regular update routine is the arrangement many teams settle on. Our post on dependency pinning versus ranges goes deeper.
Where Safeguard fits
Safeguard can do the inventory and watching for you. Its SBOM and dependency scanning lists what a repository actually pulls in, reachability analysis helps separate reachable findings from noise, and policies can gate a pull request. You can try a free scan on a repository to see the output.
Quick check
Does ^0.2.3 behave like ^1.2.3?
No. For versions below 1.0.0, the leftmost non-zero part is the minor number, so the caret range is narrower. Check the semver notes linked in the npm docs before relying on it.
If I have a lockfile, can a caret still hurt me?
Only at update time. Running npm update or deleting the lockfile lets npm pick newer versions inside the range. Review that diff like any other code change.
Sources
- npm Docs: package.json (dependencies and version ranges)
- npm Docs: npm install (save-exact)
- npm Docs: package-lock.json
Last reviewed: 19 October 2026.
