Semver Comparator - Free Online Tool | PivaBox

Compare semantic version numbers to determine which is newer, older, or equal

Semver Comparator — Compare Semantic Version Numbers to Determine Which Is Newer, Older, or Equal with Full Pre-Release and Build Metadata Support

Enter two semantic version numbers in the input fields using the format MAJOR.MINOR.PATCH (e.g., 1.2.3 and 2.0.0). Semantic Versioning (SemVer) is the de facto standard for software versioning — it gives meaning to version numbers through a strict three-part scheme: MAJOR version increments when you make incompatible API changes (breaking changes), MINOR version increments when you add backward-compatible functionality, and PATCH version increments when you make backward-compatible bug fixes. Understanding how versions compare is essential for dependency management, API compatibility checking, and automated release pipelines.
The tool automatically compares the two versions component by component according to the SemVer 2.0.0 specification precedence rules. The comparison logic: (1) Precedence is determined by the first difference when comparing MAJOR, MINOR, and PATCH numerically from left to right — 2.0.0 > 1.9.9 because MAJOR 2 > 1. (2) When MAJOR, MINOR, and PATCH are equal, a pre-release version (one with a hyphen suffix like 1.0.0-alpha) has LOWER precedence than the normal version (1.0.0) — this means 1.0.0 is 'newer' than 1.0.0-beta. (3) Pre-release identifiers are compared numerically (if both are numbers) or lexically (if both are strings) — 1.0.0-alpha.1 < 1.0.0-alpha.2 < 1.0.0-beta. (4) Build metadata (the + suffix, e.g., 1.0.0+build.123) is IGNORED when determining version precedence.
Read the result: the tool displays which version is newer (>), which is older (<), or if they are equal (=). The comparison result is color-coded for instant readability — green for one version being newer, gray for equal. Use the Semver Comparator to: check if a dependency update is safe (does the new version change the MAJOR number? If so, expect breaking changes), verify that your package.json version ranges are correct (does ^1.2.3 actually resolve to the expected version?), debug CI/CD pipelines where version comparison logic determines deployment actions, and teach junior developers how semantic versioning works through interactive comparison. All comparison happens locally in your browser — your version strings, which may reveal internal release schedules, never leave your device.

Frequently Asked Questions

What exactly do MAJOR, MINOR, and PATCH mean in Semantic Versioning, and what constitutes a 'breaking change'?

The SemVer 2.0.0 specification (semver.org) defines each component precisely. MAJOR (X in X.Y.Z): increments when you make incompatible API changes. The definition of 'breaking change' is intentionally strict — any change that could cause existing code to fail, however unlikely: removing a public method, changing a function's parameter order, changing the return type, removing an exported constant, changing error behavior, or even fixing a bug that some consumers relied on (Hyrum's Law: with enough users, every observable behavior will be depended upon by someone). MINOR (Y in X.Y.Z): increments when you add functionality in a backward-compatible manner — new methods, new optional parameters, new configuration options, deprecation warnings (but NOT removal). PATCH (Z in X.Y.Z): increments for backward-compatible bug fixes — internal implementation changes that don't affect the public API, performance improvements that don't change behavior, security patches that don't alter interfaces. The 0.Y.Z range (0.x.x) is special — anything MAY change at any time; the public API is not considered stable. The first stable release is conventionally <code>1.0.0</code>. The PivaBox Semver Comparator helps you verify version ordering against these rules.

How do pre-release labels and build metadata affect version comparison, and what are the common pre-release naming conventions?

Pre-release labels (the hyphen suffix) and build metadata (the plus suffix) serve different roles in the versioning lifecycle. Pre-release labels indicate that a version is unstable and may not satisfy the intended compatibility as indicated by its MAJOR.MINOR.PATCH numbers. Common pre-release naming conventions: <code>-alpha</code> (early internal testing, features incomplete), <code>-beta</code> (feature-complete but undergoing testing), <code>-rc</code> or <code>-rc.1</code> (release candidate, potentially final unless bugs found), <code>-dev</code> or <code>-snapshot</code> (development builds). Pre-release precedence: <code>1.0.0-alpha</code> < <code>1.0.0-alpha.1</code> < <code>1.0.0-beta</code> < <code>1.0.0-beta.2</code> < <code>1.0.0-rc.1</code> < <code>1.0.0</code>. Note that <code>1.0.0-alpha</code> is treated as <code>1.0.0-alpha.0</code> when compared against <code>1.0.0-alpha.1</code> (shorter pre-release identifier lists have lower precedence when they share a common prefix). Build metadata (e.g., <code>1.0.0+build.20240101.abcdef</code>) is completely ignored in precedence comparison — <code>1.0.0+build.1</code> and <code>1.0.0+build.2</code> are considered EQUAL versions. Build metadata is purely informational — used for CI build IDs, commit hashes, or packaging timestamps. The PivaBox comparator implements all these rules correctly.

How do version ranges in package.json (^, ~, >=, etc.) relate to semver comparison, and how do package managers resolve them?

Package managers use semver comparison to resolve version ranges into concrete versions. Common range operators: ^ (caret) — compatible with the specified version: <code>^1.2.3</code> matches <code>>=1.2.3 <2.0.0</code> (allow MINOR and PATCH bumps, block MAJOR bumps that would introduce breaking changes). This is the npm default. ~ (tilde) — approximately equivalent: <code>~1.2.3</code> matches <code>>=1.2.3 <1.3.0</code> (allow only PATCH bumps). More conservative than caret. >= < > <= — explicit numeric comparisons using semver precedence rules. * or x — wildcard: <code>1.x</code> matches <code>>=1.0.0 <2.0.0</code>. || (pipe) — union of ranges: <code>1.0 || >=1.2.7 <2.0.0</code>. When you run <code>npm install</code> or <code>yarn install</code>, the package manager: (1) reads all dependency ranges from <code>package.json</code>, (2) constructs a constraint satisfaction problem (which concrete versions satisfy all range constraints simultaneously, including transitive dependencies?), (3) solves it using a SAT solver or heuristic algorithm, (4) writes the resolved concrete versions to the lockfile (<code>package-lock.json</code>, <code>yarn.lock</code>). The PivaBox Semver Comparator helps you manually verify version ordering to debug resolution issues — e.g., why does npm choose version 1.5.0 when you specified <code>^1.2.0</code>? Because 1.5.0 falls within the <code>>=1.2.0 <2.0.0</code> range and is the highest satisfying version (assuming no other constraints).