liminfoSemVer Calculator
Free web tool: SemVer Calculator
Comparison Result
1.2.3 < 1.3.0
About SemVer Calculator
The SemVer Calculator is a free tool for working with Semantic Versioning (SemVer), the versioning standard defined at semver.org and used by npm, Cargo, Composer, and most modern package managers. It provides two modes: Version Compare, which determines whether version A is greater than, less than, or equal to version B, and Range Test, which checks whether a version string satisfies a range constraint such as ^1.2.0, ~2.3.1, or >=3.0.0.
Package managers, DevOps engineers, and open source maintainers rely on SemVer to communicate the nature of changes in software releases. A major version bump (1.x.x to 2.x.x) signals breaking changes, a minor version bump (x.1.x to x.2.x) signals new backwards-compatible features, and a patch version bump (x.x.1 to x.x.2) signals bug fixes. Understanding range operators like caret (^) and tilde (~) is essential for writing correct dependency constraints in package.json, Cargo.toml, or composer.json files.
Technically, the tool parses version strings against the semver regex pattern v?MAJOR.MINOR.PATCH[-prerelease][+build], comparing the numeric components in order (major, then minor, then patch). Pre-release identifiers lower a version's precedence — so 1.0.0-alpha is less than 1.0.0. The caret (^) operator allows changes that do not modify the left-most non-zero digit, and the tilde (~) operator allows patch-level changes when both major and minor are specified.
Key Features
- Version Compare mode — immediately shows whether version A is greater than, less than, or equal to version B
- Range Test mode — checks if a version satisfies a range using ^, ~, >=, <=, >, or = operators
- Caret (^) range: allows changes to minor and patch while keeping the same major version
- Tilde (~) range: allows only patch-level changes within the same major.minor version
- Pre-release identifier support — correctly orders versions like 1.0.0-alpha, 1.0.0-beta, and 1.0.0
- Accepts versions with or without leading v prefix (e.g., v1.2.3 and 1.2.3 are both valid)
- Real-time results — comparison and range results update instantly as you type
- 100% client-side calculation — no data is sent to any server
Frequently Asked Questions
What does Semantic Versioning (SemVer) mean?
Semantic Versioning is a versioning convention where a version number has the form MAJOR.MINOR.PATCH. You increment MAJOR when you make incompatible API changes, MINOR when you add functionality in a backwards-compatible manner, and PATCH when you make backwards-compatible bug fixes. Pre-release versions can be denoted with a hyphen (e.g., 1.0.0-alpha).
What is the difference between the ^ and ~ range operators?
The caret (^) allows changes that do not modify the left-most non-zero digit. For example, ^1.2.3 allows any version >=1.2.3 and <2.0.0. The tilde (~) allows patch-level changes when minor is specified: ~1.2.3 allows >=1.2.3 and <1.3.0. Caret is more permissive (allows minor bumps), tilde is more restrictive (patch only).
How does version comparison work for pre-release versions?
According to the SemVer specification, a pre-release version has lower precedence than the associated normal version. So 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-rc.1 < 1.0.0. The calculator compares pre-release identifiers lexicographically when the major.minor.patch components are identical.
Does ^0.x.x behave the same as ^1.x.x?
No. Because the major version is 0, the left-most non-zero digit is the minor version. So ^0.2.3 allows >=0.2.3 and <0.3.0, not <1.0.0. This is because versions starting with 0.x are considered unstable and minor bumps may contain breaking changes. Similarly, ^0.0.3 only allows >=0.0.3 and <0.0.4.
What is a build metadata identifier and does it affect version ordering?
Build metadata is appended after a plus sign (e.g., 1.0.0+20240101). According to the SemVer spec, build metadata has no effect on version precedence — two versions that differ only in build metadata are considered equal for comparison purposes. The calculator accepts versions with build metadata in the input.
How do I check if my installed package version satisfies a package.json range?
Switch to Range Test mode, enter the range from your package.json (e.g., ^4.17.1) in the Range field, and enter the installed version in the Test Version field. The result will immediately show Match or No Match. A green Match means the installed version satisfies the declared dependency constraint.
Why is 2.0.0 not satisfied by the range ^1.2.3?
The caret range ^1.2.3 allows any version >=1.2.3 and <2.0.0. Version 2.0.0 is exactly at the exclusive upper boundary, so it does not satisfy the range. This is by design — a major version bump signals breaking changes, and the caret operator is intentionally conservative about crossing major version boundaries.
What happens if I enter an invalid version string?
The tool expects versions in the format MAJOR.MINOR.PATCH with optional pre-release and build metadata suffixes. If you enter a string that does not match this pattern (e.g., just "1.2" or "latest"), the comparison displays "Invalid version" and the range test returns No Match. Make sure to use the full three-part numeric format.