Semantic Version Bumper & Comparator

About this tool

Bumps a semantic version number (major/minor/patch/prerelease) following the official semver rules, or compares two versions to see which one is actually newer — including correct handling of prerelease tags like 1.2.3-beta.1, which sort before their final release 1.2.3.

The three-number contract. Semantic versioning turns a version number into a promise about compatibility, not just a counter. Given MAJOR.MINOR.PATCH: increment PATCH for a backwards-compatible bug fix, MINOR for backwards-compatible new functionality, and MAJOR for a breaking change. Bumping a higher part always resets everything below it to zero — going from 1.5.2 to a major bump gives 2.0.0, not 2.5.2, since a new major version's minor and patch history starts fresh.

Prerelease versions mark a build as not-yet-final: 1.2.3-beta.0, then 1.2.3-beta.1 on the next prerelease bump, and so on, until the plain 1.2.3 ships. Per the spec, every prerelease of a version sorts before that version's final release — 1.2.3-beta.1 < 1.2.3-beta.2 < 1.2.3 — because a prerelease is, by definition, an earlier, less-finished build of the same target version, not a later one.

Comparing two versions matters anywhere software checks "is an update available?" or "does this dependency satisfy my minimum version?" — a dependency manager, an auto-updater, or a CI gate that blocks downgrading a package. The comparison here follows the same three-step precedence the spec defines: compare major, then minor, then patch numerically; if those are all equal, a build with no prerelease tag outranks one with a prerelease tag, and otherwise the prerelease identifiers are compared piece by piece (numeric pieces compare as numbers, alphanumeric pieces compare alphabetically).

Build metadata (a + suffix like 1.2.3+build.45) is accepted and preserved but explicitly ignored when comparing versions, per the spec — two versions differing only in build metadata are considered equal for ordering purposes, since that metadata is meant for traceability (a CI build number, a commit hash), not for version precedence.

Everything runs locally in your browser — nothing is uploaded.

Frequently asked questions

What's the difference between major, minor, and patch?

Per semver convention: patch is for backwards-compatible bug fixes, minor is for backwards-compatible new features, and major is for breaking changes. Bumping major or minor resets the lower parts to zero (e.g. 1.5.2 → major bump → 2.0.0).

Why does 1.2.3-beta.1 compare as "older" than 1.2.3?

This is a deliberate rule in the semver spec — a version with a prerelease tag is considered a pre-release of that version, not a later one, so it always sorts before the plain (final) release with the same major.minor.patch.

What versions does this accept?

Standard MAJOR.MINOR.PATCH with an optional -prerelease and/or +build suffix (build metadata is accepted but ignored for comparison, per the spec) — an optional leading v is also accepted and stripped.

What happens the second time I bump "prerelease"?

If the version already has a numeric prerelease identifier, it's incremented — 1.2.3-beta.0 becomes 1.2.3-beta.1 on the next prerelease bump, rather than restarting at .0 or appending a second label.

Does build metadata affect version comparison?

No — per the spec, 1.2.3+build.1 and 1.2.3+build.2 are treated as equal when comparing, since build metadata is for traceability, not precedence.

Why does a version with no prerelease outrank one with a prerelease, at the same major.minor.patch?

Because a prerelease is explicitly an earlier, unfinished build of that version — 1.0.0 is the version 1.0.0-rc.1 was building toward, so it has to sort later.

Is a leading "v" (like v1.2.3) accepted?

Yes — it's a common convention in git tags and changelogs, so it's stripped automatically before parsing either input.