Semver Comparator
Compare semantic version numbers and validate version ranges
Compare Versions
Enter the first semantic version (e.g., 1.2.3, 2.0.0-beta)
Enter the second semantic version to compare
Validate Range
Enter a version to check against a range
Enter a semver range (^, ~, >=, <, etc.)
What is Semantic Versioning (Semver)?
Semantic Versioning is a versioning scheme that uses a three-part number format: MAJOR.MINOR.PATCH (e.g., 2.1.3). Each part has specific meaning: increment MAJOR for breaking changes, MINOR for new backward-compatible features, and PATCH for backward-compatible bug fixes. This standard helps developers understand the impact of updating dependencies.
How to Use
- Enter two versions in the comparison section to see which is greater
- Use the range validator to check if a version satisfies a range expression
- The tool supports prerelease versions (alpha, beta, rc) and build metadata
- Common range operators: ^ (caret), ~ (tilde), >=, <=, <, >, =
Version Format
A valid semantic version consists of three required numeric parts and optional prerelease and build metadata:
- MAJOR: Incompatible API changes (e.g., 2.0.0)
- MINOR: Backward-compatible new features (e.g., 1.3.0)
- PATCH: Backward-compatible bug fixes (e.g., 1.2.5)
- Prerelease: Optional identifier like -alpha, -beta.1, -rc.2
- Build metadata: Optional identifier like +build.123
Range Expressions
Semver ranges allow you to specify acceptable version ranges for dependencies:
- ^1.2.3: Compatible with 1.2.3, allows 1.x.x (but not 2.0.0)
- ~1.2.3: Compatible with 1.2.3, allows 1.2.x (but not 1.3.0)
- >= 1.0.0 < 2.0.0: Any version from 1.0.0 up to (but not including) 2.0.0
- 1.2.x: Any patch version in the 1.2 series
- *: Any version
Prerelease Versions
Prerelease versions are denoted by appending a hyphen and identifiers (e.g., 1.0.0-alpha). They are always considered less than the corresponding release version. Common prerelease identifiers include alpha (early testing), beta (feature complete but may have bugs), and rc (release candidate, final testing before release).
Common Use Cases
- Dependency Management: Specify acceptable version ranges in package.json
- Release Planning: Determine the next version number based on changes
- Compatibility Checking: Verify if a version satisfies requirements
- Version Sorting: Order versions correctly in release lists
- API Versioning: Communicate breaking changes to API consumers
Best Practices
- Start with version 1.0.0 for your first stable release
- Use 0.x.x for initial development where anything may change
- Increment MAJOR version for breaking changes to signal incompatibility
- Use prerelease versions for testing before official releases
- Document breaking changes clearly in release notes
- Follow semver strictly to maintain trust with your users
Frequently Asked Questions
How do I compare two semantic versions?
Enter both versions in the comparison section and click "Compare". The tool will show which version is greater, less, or if they're equal. It also displays the type of difference (major, minor, patch, or prerelease).
What does the caret (^) mean in version ranges?
The caret (^) allows changes that do not modify the left-most non-zero digit. For example, ^1.2.3 allows versions from 1.2.3 up to (but not including) 2.0.0. This is useful for accepting backward-compatible updates.
What does the tilde (~) mean in version ranges?
The tilde (~) allows patch-level changes if a minor version is specified, or minor-level changes if not. For example, ~1.2.3 allows versions from 1.2.3 up to (but not including) 1.3.0. This is more restrictive than the caret.
How are prerelease versions compared?
Prerelease versions are always less than their corresponding release versions. When comparing two prerelease versions, identifiers are compared lexically. For example: 1.0.0-alpha < 1.0.0-beta < 1.0.0-rc.1 < 1.0.0.
Can I use version ranges with multiple conditions?
Yes! You can combine multiple conditions using spaces. For example, ">=1.0.0 <2.0.0" means any version from 1.0.0 up to (but not including) 2.0.0. You can also use || for OR conditions.
What if my version doesn't follow semver format?
The tool will display an error if the version doesn't follow semantic versioning format. Valid versions must have three numeric parts (MAJOR.MINOR.PATCH) and optionally prerelease or build metadata. Examples: 1.0.0, 2.1.3-beta, 1.0.0+build.123.
How do I determine the next version number?
Follow semver rules: increment MAJOR for breaking changes, MINOR for new backward-compatible features, and PATCH for backward-compatible bug fixes. Use prerelease versions (alpha, beta, rc) for testing before official releases.