No Login Data Private Local Save

npm Version Range Checker - Online SemVer & Tilde Caret

68
0
0
0

NPM Version Range Checker

Parse, visualize, and validate npm-style semver ranges — ^1.2.3, ~1.2.3, >=1.0.0 <2.0.0, and more.

Invalid range expression. Please check syntax.
^1.2.3 ~1.2.3 >=1.2.3 <2.0.0 1.2.x ^0.2.3 ~0.2.3 >=1.5.0 || >=2.0.0 1.2.3 - 2.3.4 * (any) ^1.0.0-alpha.1
Range Analysis
Enter a range above to see its breakdown
Equivalent Expression
Minimum Version
—
Maximum Version
—
Range Coverage
— —
Sub-ranges (OR clauses)
Range includes pre-release versions
Version Check
Please enter a valid semver version (e.g. 1.2.3)
Enter a version above to test it
Version Match Visualization
—
Enter a range to see matching versions
Matches No match

Frequently Asked Questions

What is Semantic Versioning (SemVer)?

SemVer uses a three-part version number: MAJOR.MINOR.PATCH. Increment MAJOR for breaking changes, MINOR for new backward-compatible features, and PATCH for backward-compatible bug fixes. Optional pre-release labels (e.g., 1.0.0-alpha.1) and build metadata (e.g., 1.0.0+build.123) can be appended.

What does ^ (caret) mean in npm version ranges?

The caret ^ allows changes that do not modify the leftmost non-zero digit. For example, ^1.2.3 means >=1.2.3 <2.0.0 — compatible with 1.x.x. For ^0.2.3, it means >=0.2.3 <0.3.0, and for ^0.0.3 it pins to >=0.0.3 <0.0.4. This is npm's default when you run npm install.

What does ~ (tilde) mean?

The tilde ~ is more conservative. ~1.2.3 means >=1.2.3 <1.3.0 — only patch-level changes are allowed. ~1.2 means >=1.2.0 <1.3.0, and ~1 means >=1.0.0 <2.0.0. Use tilde when you want stricter control over dependency updates.

What's the difference between ^ and ~ in practice?

^1.2.3 accepts any 1.x.x version ≥1.2.3 (including 1.9.9), while ~1.2.3 only accepts versions from 1.2.3 up to (but not including) 1.3.0. Use ^ for libraries with stable APIs; use ~ for dependencies where you want minimal change risk.

How do pre-release versions interact with ranges?

By default, npm ranges do not match pre-release versions unless the range itself specifies a pre-release tag. For example, ^1.2.3 will not match 1.3.0-beta.1, but ^1.2.3-beta will match 1.3.0-beta.5. This prevents accidental upgrades to unstable releases.

What are wildcard ranges like 1.2.x or *?

1.2.x (or 1.2.*) matches any version >=1.2.0 <1.3.0 — equivalent to ~1.2.0. * (or just empty) matches any version at all (>=0.0.0). Use wildcards sparingly as they can lead to unpredictable dependency resolution.

How does the hyphen range 1.2.3 - 2.3.4 work?

A hyphen range like 1.2.3 - 2.3.4 translates to >=1.2.3 <=2.3.4 (inclusive on both ends). Partial versions are filled in: 1.2 - 2.3.4 becomes >=1.2.0 <=2.3.4. This syntax is common in package.json dependencies.

Can I combine multiple ranges with ||?

Yes! Use || to specify alternative ranges. For example, ^1.0.0 || ^2.0.0 matches any version in the 1.x range (≥1.0.0) or the 2.x range (≥2.0.0). This is useful when your package supports multiple major versions of a dependency.

Why should I lock my dependency versions?

While ranges like ^1.2.3 provide flexibility, they can introduce non-deterministic builds. Using a lockfile (package-lock.json or yarn.lock) pins exact versions while still allowing range-based resolution during updates. Combine ranges in package.json with a committed lockfile for the best balance of flexibility and reproducibility.

What happens if I use an invalid or empty range?

An empty string or * matches any version. An invalid expression (like ^^1.0 or abc) will be treated as an error by npm and most package managers. Always validate your ranges before publishing package.json to avoid unexpected resolution failures.

🔧 Related Tools