search

Found

info Overview

Parse two version strings per SemVer 2.0.0 into major, minor, patch and pre-release, then return a strict A < B / A = B / A > B precedence verdict.

📘 How to Use

  1. Enter the first version string in the Version A field
  2. Enter the second version string in the Version B field
  3. Read the result symbol and the major / minor / patch / pre-release / build breakdown

SemVer Version Comparator

※ Comparison follows the SemVer 2.0.0 precedence rules (https://semver.org/).

※ Build metadata (after +) is ignored when computing precedence.

Result
—
—

A breakdown

major
—
minor
—
patch
—
pre-release
—
build
—

B breakdown

major
—
minor
—
patch
—
pre-release
—
build
—
Copied

grid_view Related

Article

SemVer Version Comparator | Decide which version is newer per SemVer 2.0.0 precedence

Parse two version strings against the SemVer 2.0.0 spec, split them into major / minor / patch / pre-release / build, and get a strict precedence verdict. Edge cases like 1.2.3 versus 1.10.0-rc.1 are made transparent with a symbol and a component breakdown.

💡 About this tool

String comparison and version comparison are not the same thing. Sort 1.9.0 and 1.10.0 as plain text and 9 looks bigger than 1, so 1.9.0 wins — which is wrong. SemVer compares the minor field numerically, so 1.10.0 is the newer release. This "9 versus 10" gotcha is exactly the kind of thing that bites you when reviewing a lockfile diff or deciding whether an upgrade is safe.

Paste two versions and the tool parses each one, compares major / minor / patch as integers, then applies the pre-release precedence rules, returning A < B, A = B, or A > B. Each version is split into its components in a vertical card so you can see why the verdict came out the way it did. Build metadata (everything after +) is ignored for precedence per the spec — and the breakdown shows that behaviour clearly.

🧐 Frequently Asked Questions

Is 1.0.0-alpha older or newer than 1.0.0? 1.0.0 is newer. A pre-release version always has lower precedence than the associated normal release with the same major.minor.patch.

How does 1.0.0-alpha.1 compare to 1.0.0-alpha.beta? Identifiers are split on dots and compared left to right. Numeric identifiers compare numerically, identifiers with letters compare in ASCII sort order, and a purely numeric identifier always ranks lower than one containing letters.

Do two versions that differ only in build metadata count as different? No. 1.0.0+build.1 and 1.0.0+build.999 have equal precedence (A = B). Build metadata is excluded from comparison.

Can I paste v1.2.3 with a leading v? Yes — a leading v, V, or = is stripped before parsing. The cleaned string still has to be valid SemVer 2.0.0 (MAJOR.MINOR.PATCH).

What about a short string like 1.2 or 1? SemVer 2.0.0 requires all three numbers, so 1.2 is treated as invalid. Pad it to 1.2.0 and it will parse.

📚 Why precedence is harder than it looks

SemVer was published by GitHub co-founder Tom Preston-Werner to give MAJOR.MINOR.PATCH numbers a shared meaning: bump MAJOR for breaking changes, MINOR for backward-compatible features, PATCH for backward-compatible fixes. Package managers such as npm and Cargo lean on these semantics to resolve dependency ranges.

The part developers get wrong most often is pre-release ordering. The spec defines a precise algorithm: when all preceding identifiers are equal, a larger set of pre-release fields has higher precedence, so 1.0.0-alpha.1 is older than 1.0.0-alpha.1.1. Because the rules are easy to misremember, putting two candidate versions side by side and reading the breakdown is a quick sanity check before you trust a comparator buried inside a CI script.