Skip to content
littlekit.app

SemVer range tester

Test a complete SemVer version against a documented local range subset and export the decision.

Range decision11 chars
Complete SemVer, for example 1.2.3-beta.1.
Exact, comparisons, ^, ~, x wildcards, hyphen, and ||.
Live range decision Ready
Matches this range
1.5.0 matches ^1.2.3

Uses a documented SemVer subset: exact versions, comparison sets, caret/tilde, x wildcards, hyphen ranges, and OR alternatives.

Processed on your device

How it works & useful details

Test a documented SemVer subset

Compare one complete SemVer version with an exact version, a whitespace-separated comparator set, a caret or tilde range, x/* wildcard, hyphen range, or || alternatives.

Build metadata is ignored for precedence. Prerelease values compare under core SemVer precedence, but this small local tester deliberately does not reproduce npm’s full prerelease-gating and range grammar.

Private, bounded text processing

Code and markup stay as inert text in this browser. These tools do not execute JavaScript, render HTML, load URLs, install packages, contact registries, or save what you paste.

Regex patterns are limited to 500 characters and test text to 20,000 characters. Formatters and package inspection accept up to 100,000 characters; exports are capped at 200,000 characters.

About this tool

SemVer range tester checks whether a complete semantic version satisfies a range expression, using a documented subset of the npm range syntax. It answers questions like whether 2.4.1 falls inside ^2.3.0 without installing anything.

The decision is computed locally and exported as text, including the normalized range and the tested version. Constructs outside the supported subset are reported instead of guessed.

How to use it

  1. Enter the range expression, such as ^1.2.0 or ~3.4.5.
  2. Enter the complete version you want to test.
  3. Read whether the version satisfies the range and how the range was normalized.
  4. Copy the decision for a changelog, review, or issue comment.

Worked examples

1.2.3        ~1.2.0                     matches
1.3.0        ~1.2.0                     does not match
2.0.0        ^1.2.3                     does not match
0.2.5        ^0.2.3                     matches
0.3.0        ^0.2.3                     does not match
1.5.0        >=1.2.0 <2.0.0 || 3.x      matches

Tilde (~) allows patch updates only. Caret (^) allows minor and patch updates, but below 1.0.0 it is stricter: ^0.2.3 means >=0.2.3 <0.3.0, because pre-1.0 minor versions are allowed to break compatibility.

Reading version ranges

Semantic Versioning uses MAJOR.MINOR.PATCH: breaking changes bump the major number, new features the minor, and fixes the patch. Ranges in package.json express how much change you are willing to accept automatically. ^ is npm's default when you run npm install, and a lockfile then pins the exact version that was installed.

Prerelease versions such as 1.2.4-beta.1 are compared using SemVer precedence, so 1.2.4-beta.1 matches ^1.2.3 here. npm is stricter. It only lets a range match a prerelease when a comparator in the range names the same major.minor.patch with a prerelease tag. Check such cases with npm itself before relying on them.

Frequently asked questions

Which range operators are supported?

Common npm forms such as exact versions, ^, ~, comparison operators, and hyphen ranges. Unsupported constructs are listed in the report.

Does it resolve prerelease or build metadata the same way as npm?

The tested subset is documented in the tool. Edge cases such as prerelease ordering may differ from a specific package manager’s resolution.

What is the limit?

Up to 256 characters across the range and version inputs.

Does build metadata like +build.5 affect matching?

No. Build metadata is ignored for precedence, as the SemVer specification requires.