b2KIT

Semantic Versioning Calculator

Parse, compare, and increment semantic version numbers with range validation and compatibility checking.

Tested tool guide Tested browser tools Checked August 16, 2026

What Semantic Versioning Calculator does, with a checked example

A calculator for Semantic Versioning 2.0.0 strings. Paste a version such as 2.3.1-alpha.2+build.7 and the tool validates the syntax, splits it into major, minor, patch, pre-release, and build parts, compares two versions using the spec's precedence rules, and steps a version forward by bumping one segment while zeroing the segments after it. A range field tests a version against npm-style expressions like ^2.3.0 or ~1.2.x. The recurring surprise: 1.2.0-rc.1 does not satisfy ^1.2.0 even though it is ahead of the range's lower bound, because ranges exclude pre-releases unless the range itself names one.

Worked example

A concrete input and expected output from the current implementation.

Input

2.3.1-alpha.2+build.7
Compare: 2.3.1-alpha.2 vs 2.3.1
Increment: minor on 2.3.1
Range: does 2.3.1-alpha.2 satisfy ^2.3.0?

Expected output

Valid: major 2, minor 3, patch 1; pre-release [alpha, 2]; build [build, 7].
Compare: 2.3.1-alpha.2 is lower - a pre-release sorts below the same version without one.
Increment: 2.4.0 - the patch segment resets to zero.
Range: no - ^2.3.0 (>=2.3.0 <3.0.0) excludes pre-releases unless the range names one.

Each result follows the SemVer 2.0.0 rules: pre-releases rank below their associated release, a minor bump zeroes everything after it, and npm-style ranges only match pre-releases when the range itself carries one. The plain version 2.3.1, by contrast, does satisfy ^2.3.0.

How the result is produced

1

Parsing and validation

The string is split on dots into major, minor, and patch, which must be non-negative integers without leading zeros, so 01.2.3 is rejected. An optional pre-release follows the hyphen, as dot-separated identifiers where numeric ones again carry no leading zeros; an optional build suffix follows the plus sign. Anything else fails validation instead of being guessed at.

2

Precedence comparison

Major, then minor, then patch are compared numerically. On a tie, a version with a pre-release sorts below the same version without one. Between pre-releases, numeric identifiers compare by value, alphanumeric identifiers by ASCII order, and a numeric identifier always sorts below an alphanumeric one. Build metadata never breaks a tie. These rules come from the specification itself.

Good uses

  • Choosing the next release number: decide whether the change is breaking (major), feature-adding (minor), or a fix (patch), then confirm the reset-to-zero result before tagging.
  • Explaining a dependency resolution: paste the range from your package manifest and the version your package manager installed to see why, or whether, it fits.
  • Settling pre-release comparisons, such as whether 1.0.0-rc.2 is newer than 1.0.0-beta.3, before merging a release candidate.

Limits and checks

  • Range matching excludes pre-releases by default: ^1.2.0 does not match 1.2.1-beta.1 even though that version is newer than the range's lower bound. A range matches a pre-release only when it carries one itself.
  • Leading zeros change validity: 01.2.3 and 1.02.3 are invalid under the spec and rejected, while some other version tools silently accept and normalize them, so the same string can behave differently across tools.
  • Caret ranges behave differently below 1.0.0: under npm conventions ^0.2.3 means >=0.2.3 <0.3.0, not any 0.x. If you expect 0.4.0 to fit, the miss is deliberate, not a bug.

Common questions

Why does 1.0.0+a compare equal to 1.0.0+b?

Because the specification says build metadata is ignored when determining precedence; the two versions are equal in ordering even though the strings differ. The tool can still display the metadata and compare the strings exactly, so equal for precedence and identical string are different answers to different questions.

What does bumping minor on 1.2.9 give me?

1.3.0. A minor bump adds one to the minor segment and resets patch to zero; a major bump on 2.7.4 likewise gives 3.0.0. Patching 1.2.9 gives 1.2.10 - the segments carry like decimal digits, but each is compared as its own number, not as one combined number.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools