Semver Comparator
Compare semantic version numbers. Parse and sort semver strings, check if a version satisfies a range, and understand major/minor/patch differences.
Compare Two Versions
1.2.3
OLDER
2.0.0-beta.1MAJOR version change
| Major | Minor | Patch | Pre-release | |
|---|---|---|---|---|
| 1.2.3 | 1 | 2 | 3 | — |
| 2.0.0-beta.1 | 2 | 0 | 0 | beta.1 |
Version Range Check
✓ 1.5.0 satisfies ^1.2.0
Sort Version List
One version per line — sorted newest first
13.0.0-beta.1beta.1
22.1.0
32.1.0-11
42.0.0-rc.1rc.1
51.2.3
61.0.0
71.0.0-betabeta
81.0.0-alphaalpha
How to Use Semver Comparator
- 1Enter two version numbers to compare (e.g. 1.2.3 vs 2.0.0).
- 2See which is newer and what changed (major/minor/patch).
- 3Sort a list of semver versions.
- 4Check if a version satisfies a range constraint like ^1.2.0.
Zenovay
Track your website performance
Real-time analytics, session replay, heatmaps, and AI insights. 2-minute setup, privacy-first.
Related Tools
JSON Formatter & ValidatorFormat, validate, and beautify JSON data with syntax highlighting and error detection.
JWT DecoderDecode and inspect JWT tokens. View header, payload, and verify signatures.
Base64 Encode/DecodeEncode text to Base64 or decode Base64 back to text. Supports UTF-8 and binary data.
URL Encode/DecodeEncode or decode URL components. Handle special characters, query strings, and full URLs.
Frequently Asked Questions
What is semantic versioning?▾
Semantic versioning (semver) is a versioning convention using the format MAJOR.MINOR.PATCH. MAJOR: incompatible API changes (breaking). MINOR: new backward-compatible functionality. PATCH: backward-compatible bug fixes. Pre-release versions append a hyphen and identifiers: 1.0.0-alpha, 1.0.0-beta.1, 1.0.0-rc.1. Build metadata appends a plus sign: 1.0.0+build.42. Defined at semver.org by Tom Preston-Werner (GitHub co-founder).
How are semver versions compared?▾
Versions are compared left to right: MAJOR first, then MINOR, then PATCH. When these are equal, a pre-release version has lower precedence than the release: 1.0.0-alpha < 1.0.0. Pre-release identifiers are compared as numbers if numeric, strings otherwise (lexicographically). Longer pre-release has higher precedence when all prior fields match: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2.
What do npm version range operators mean?▾
^1.2.3 (caret): compatible with, allows MINOR and PATCH updates — ≥1.2.3 <2.0.0. ~1.2.3 (tilde): approximately equivalent, allows only PATCH updates — ≥1.2.3 <1.3.0. 1.2.x or 1.2.*: any PATCH. * or x: any version. >1.2.3, >=1.2.3, <2.0.0: explicit ranges. 1.2.3 - 2.3.4: inclusive range. These ranges are evaluated by npm, Yarn, pnpm, and tools like Renovate and Dependabot.
When should I increment MAJOR vs MINOR vs PATCH?▾
MAJOR (x.0.0): when you make incompatible API changes — removed functions, changed function signatures, breaking behavior changes, deleted CLI flags. MINOR (1.x.0): when you add functionality in a backward-compatible manner — new functions, new optional parameters, new configuration options. PATCH (1.0.x): when you make backward-compatible bug fixes — fixing incorrect behavior, security patches, performance improvements with no API change.
What is the difference between pre-release and build metadata?▾
Pre-release (1.0.0-alpha.1): affects version precedence — 1.0.0-alpha.1 < 1.0.0. Used for alpha, beta, release candidates. Build metadata (1.0.0+build.1): does NOT affect version precedence — 1.0.0+build.1 == 1.0.0 for comparison purposes. Build metadata is often used for CI build numbers, git commit hashes, or build timestamps. Per semver spec, two versions differing only in build metadata are equal.