🏷️ Semver Checker & Comparator

Validate a semantic version string (major.minor.patch, with optional pre-release and build metadata) and compare two versions to see which is newer, per the semver.org spec.

How the comparison is decided

Each string is matched against the official semver.org regular expression, then the parts are compared in this order:

major -> minor -> patch      numeric, highest wins
then: no pre-release beats any pre-release
then: pre-release identifiers, left to right
build metadata: parsed, shown, and ignored

The two defaults show it: 1.4.0-beta.2+build.5 is older than 1.4.0, because a pre-release always sorts below the release it leads to, and +build.5 carries no weight at all. Within a pre-release, all-digit identifiers compare as numbers, so beta.2 is below beta.11; a numeric identifier always ranks below an alphabetic one; and a shorter run of identifiers loses, making alpha older than alpha.1.

What counts as valid

Two versions differing only in build metadata compare as equal, exactly as the spec requires. If you need them to rank differently, the difference belongs in the pre-release field instead.

Frequently asked questions

Is 1.0.0-beta.11 newer than 1.0.0-beta.2?

Yes. Identifiers made only of digits are compared as numbers, not as text, so 11 beats 2. This is the usual reason a release train that sorted correctly as strings suddenly does not.

Does build metadata affect which version is newer?

No. It is shown for information and skipped by the comparison, so 1.4.0+exp.sha.5114f85 and 1.4.0 rank equal. Package managers ignore it for the same reason.

Why is 1.2 or v1.2.3 marked invalid?

Semver requires exactly three numeric parts and nothing before the major number. Leading zeros such as 1.02.0 are rejected too, because 02 and 2 would otherwise be two spellings of one version.