🏷️ 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
- All three numbers are required.
1.4fails; so does01.4.0, since leading zeros are banned on major, minor and patch. - No v prefix. Git tags like
v2.1.0are rejected here - strip the v, which is what npm and Go do internally too. - Build metadata is loose. Anything alphanumeric with dots and
hyphens after a
+passes, including a commit hash.
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.