CruxDevCruxDev Tools Prompts
dev Utility • Zero-Server Privacy • 100% Client-Side

Semver Calculator & Range Checker

Compare semantic versions, bump major/minor/patch, sort version lists and test npm ranges like ^1.2.0, ~1.4 and >=1 <2 with prerelease rules.

Overview

Compares two semantic versions, bumps major, minor or patch, sorts a list of versions into the correct order and tests whether a version satisfies an npm-style range such as ^1.2.0, ~1.4 or >=1.0.0 <2. It follows the semver.org precedence rules, including prerelease tags like beta.2 and rc.1.

How It Works

Enter two versions in Version A and Version B to see which is newer; invalid versions are flagged straight away. The Bump buttons under Version A apply a major, minor or patch release to it. Type a range into the range box to check whether Version A satisfies it. Paste one version per line into the sort box and the list on the right shows them oldest first, with any invalid lines listed separately. Every result updates as you type.

Step-by-Step Usage Guide

  1. Enter the version you are checking as Version A.
  2. Enter a second version to compare, or a range to test against.
  3. Use the Bump buttons to work out your next release number.
  4. Paste a list of versions to sort them and copy the ordered list.

Technical Specifications & Standards

Semantic versions look like decimals but do not sort like them. 1.10.0 is newer than 1.9.0 because each part is compared as a whole number, while a plain text sort puts 1.10.0 first. Prerelease tags add more rules, which this tool implements from section 11 of the semver.org specification. A prerelease is older than the same version without one, so 1.0.0-rc.1 comes before 1.0.0. Prerelease parts are compared one by one: numeric parts numerically, so beta.2 comes before beta.11; text parts alphabetically; numeric parts before text parts; and a shorter list comes first when everything else is equal, so alpha comes before alpha.1. Build metadata after a plus sign is ignored for ordering, so 1.0.0+build.1 and 1.0.0+build.2 are equal. Ranges follow npm. A caret allows changes that keep the left-most non-zero part, so ^1.2.3 means at least 1.2.3 and below 2.0.0, ^0.2.3 stays below 0.3.0, and ^0.0.3 matches only 0.0.3. A tilde allows patch updates, so ~1.2.3 stays below 1.3.0. x-ranges such as 1.x, hyphen ranges such as 1.0.0 - 1.4.0, space-separated comparators and || alternatives are all supported. As in npm, a prerelease version only satisfies a range that mentions a prerelease of the same major.minor.patch, which stops ^1.2.3 from silently pulling in 1.3.0-beta.1. Bumping follows npm version too: a patch bump of 1.2.3-rc.1 releases 1.2.3 itself.

Targeted Use Cases

  • Checking whether a dependency update will be picked up by the range in package.json.
  • Choosing the next version number for a release based on the kind of change.
  • Sorting release tags or changelog entries into the correct order.
  • Understanding why a beta or rc version was not installed by npm.

Notes & Gotchas

  • Bump major for breaking changes, minor for new backward-compatible features and patch for fixes.
  • Be careful with ^ on 0.x versions; it only allows patch updates while the minor part is the left-most non-zero part.
  • Publish prereleases with numbered tags such as beta.1 and beta.2 so they sort correctly.
  • Do not rely on build metadata for ordering; semver ignores it.

Frequently Asked Questions

Why is 1.10.0 newer than 1.9.0?

Each part of a version is compared as a whole number, and 10 is greater than 9. A text sort compares character by character and gets this wrong, which is why version lists need a semver-aware sort.

What does the caret (^) mean?

It allows updates that do not change the left-most non-zero part. ^1.2.3 accepts anything from 1.2.3 up to but not including 2.0.0, while ^0.2.3 accepts only 0.2.x from 0.2.3 upwards.

Why doesn't ^1.2.3 match 1.3.0-beta.1?

npm only matches a prerelease against a range that names a prerelease on the same major.minor.patch. This keeps unstable versions out of normal installs; use a range such as ^1.3.0-beta.0 to opt in.

Is build metadata compared?

No. Everything after a plus sign is ignored for ordering, so 1.0.0+001 and 1.0.0+002 have the same precedence.