Skip to content

Semver Range Tester

Checks which versions satisfy a range, compares two versions and sorts a list in precedence order.

Answers the two questions people actually have about semantic versioning: does this version satisfy this range, and which of these versions would npm install. It also compares two versions by precedence and shows what each `npm version` bump would produce.

🔒 Runs entirely in your browsersemverversionnpm

Range

Matches: 1.0.0 or later and earlier than 2.0.0

npm's range grammar: `^` `~` `x` `-` `||` and the comparison operators. This is not part of semver.org, which only defines the version format and its ordering.

Versions

One per line, or comma-separated.

Which ones match

Prereleases
  1. —1.0.0-alpha
  2. —1.0.0-alpha.1
  3. —1.0.0-alpha.beta
  4. —1.0.0-beta
  5. —1.0.0-beta.2
  6. —1.0.0-beta.11
  7. —1.0.0-rc.1
  8. matches1.0.0
  9. matches1.2.0would be installed
  10. —2.0.0-rc.1
  11. —2.0.0
  12. —2.1.3

Compare two

Order

1.0.0-beta.11 is higher

Difference

prerelease

Precedence follows semver.org clause 11 exactly, build metadata included — which is to say, ignored.

Next version

Each release type and the version it produces.
major2.0.0
minor1.3.0
patch1.2.4
premajor2.0.0-alpha.0
preminor1.3.0-alpha.0
prepatch1.2.4-alpha.0
prerelease1.2.4-alpha.0

What `npm version <type>` would produce.

One rule surprises everyone: a prerelease satisfies a range only when the range itself mentions a prerelease of the same major.minor.patch. That is why ^1.0.0 does not match 2.0.0-beta.1, and why an rc tag never installs itself by accident.

How to use it

  1. Write the range

    `^1.0.0`, `~1.2.3`, `>=1.2.7 <1.3.0`, `1.2.3 - 2.3.4` and `||` all work. A plain-English description of what it matches appears underneath.

  2. Paste the versions you have

    One per line, or comma-separated — `npm view <pkg> versions` output pastes straight in. Each is marked as matching or not, and the one npm would install is labelled.

  3. Compare two, or plan the next release

    The compare panel follows semver.org clause 11 exactly. The bump table shows what `npm version major`, `preminor` and the rest would produce from a given starting point.

Common questions

Why does `^1.0.0` not match `2.0.0-beta.1`?

Two reasons at once. `^1` never reaches major 2, and separately a prerelease only satisfies a range when the range itself names a prerelease of the same major.minor.patch. That second rule is why an `rc` tag never installs itself by accident.

Why does `^0.2.3` behave differently?

Below 1.0.0 the caret tightens to the minor: `^0.2.3` allows 0.2.x but not 0.3.0, because a 0.x project is understood to break at every minor. It is npm’s rule rather than semver.org’s, and it surprises people every time.

Is `1.0.0+build.1` different from `1.0.0`?

Different strings, same precedence — clause 10 says build metadata is ignored when comparing. Which means a sort over versions that differ only in build metadata is not stable, and two such versions cannot be ordered at all.

Is the range syntax part of semver?

No. semver.org defines the version format and how two versions compare, and stops there. `^`, `~`, `x` and `||` are npm’s range grammar, which other ecosystems either borrowed or replaced — Cargo, Composer and pip each differ in the details.

Feed it from

Next

These accept what this tool produces, so the result can go straight in.