Parse, compare, and bump semver versions

Parse, compare, bump.

Parse, compare, and increment semantic versions (MAJOR.MINOR.PATCH with optional pre-release and build metadata). Pure browser; no login.

A 1.2.3 is less than 1.3.0.

Result

Semantic versioning: what the three numbers promise

Semantic Versioning, or SemVer, gives version numbers a meaning: MAJOR.MINOR.PATCH. Raise PATCH for bug fixes, MINOR for new features that do not break anything, and MAJOR for changes that can break existing users. npm, Cargo, Composer, Go modules and most package managers rely on it to decide which updates are safe to install automatically.

This tool parses a version, compares two versions by the official precedence rules and bumps a version to the next major, minor, patch or pre-release, the same way npm version does.

How to use it

  1. Type two versions into Version A and Version B to see which one is higher.
  2. Type a version into Bump from and choose major, minor, patch or pre-release.
  3. Read the result. An invalid version is flagged instead of being guessed at.
  4. Copy the new version into your package file or release tag.

Example: bumping 1.4.2 four ways

Input
1.4.2
Output
major: 2.0.0
minor: 1.5.0
patch: 1.4.3
pre-release: 1.4.3-rc.0

A first pre-release goes on the next patch, because 1.4.2-rc.0 would sort below 1.4.2, which is already released.

Pre-releases and build metadata

A hyphen adds a pre-release label: 2.0.0-beta.1 or 2.0.0-rc.3. A pre-release always sorts below the release it leads up to, so 2.0.0-rc.3 is lower than 2.0.0. Labels are compared part by part: numeric parts as numbers, so beta.11 is above beta.2, and text parts alphabetically, so alpha comes before beta and beta before rc.

A plus sign adds build metadata, such as 1.0.0+20260326 or 1.0.0+sha.5114f85. It is ignored when comparing versions, so two builds of the same version are equal, and a bump drops it.

Bumping a pre-release releases it: major on 2.0.0-rc.1 gives 2.0.0, and patch on 1.2.4-rc.0 gives 1.2.4, matching npm.

Version ranges in package managers

Dependency ranges build on these rules. In npm, ^1.4.2 accepts anything from 1.4.2 up to, but not including, 2.0.0: new features and fixes, no breaking changes. ~1.4.2 accepts only patches, up to 1.5.0. Versions below 1.0.0 are treated as unstable, so ^0.4.2 only accepts 0.4.x, since anything may change before 1.0.

The rules that trip people up

Numbers have no leading zeros, so 01.2.3 is not valid SemVer. A leading v, as in v1.2.3, is a tagging convention and not part of the version itself; strip it before parsing. And 1.10.0 is higher than 1.9.0, because each part is compared as a number, not as text.

Questions

When should I release 1.0.0?

When people depend on your public API in production. From 1.0.0 on, breaking changes require a new major version.

Is a security fix a patch?

Yes, as long as it does not break the public API. If the fix must change behaviour people rely on, it is a major release, however small the change.

Is anything sent to a server?

No. Parsing and comparing happen in your browser.