SemVer range tester
Developer tools
Loading
Loading tool
The tool is loaded only when you open it.
All processing for this tool happens in your browser. Your input is not sent to a server.
About this tool
Enter an npm-style version range and one version per line to check only the versions you provide. The bundled node-semver 7.8.5 engine uses loose: false. Results distinguish valid matches, valid versions outside the range and invalid entries. Inspect the normalized comparator groups, an ascending list of matching versions and the minimum and maximum from that list. Comparators within a group are combined with AND; groups are combined with OR. The prerelease switch makes includePrerelease explicit. Parsing runs locally in your browser without querying a package registry or executing package code.
Common uses
- Compare caret, tilde, hyphen, wildcard and comparator ranges against a known set of package versions before editing a dependency declaration.
- Explain why a 0.x release or prerelease is excluded, then change includePrerelease to compare the exact matching rules.
- Separate malformed version rows from valid nonmatches and inspect SemVer ordering without treating build metadata as a higher release.
How to use it
- 1.Enter a range such as ^0.2.3, ~1.2.3, 1.2.3 - 2.0.0 or >=1.2.3 <2.0.0. Use || for alternatives. An empty range is the wildcard *.
- 2.Paste complete versions, one per line, and choose whether to include prereleases. Surrounding whitespace is trimmed and blank lines are skipped; version rows still require major.minor.patch.
- 3.Run the check and inspect each row, normalized groups and sorted matches. Copy or download the JSON report if needed. Editing the range, list or prerelease setting clears the result; minimum and maximum come only from matching input rows.
Worked npm SemVer examples
Caret range before 1.0.0
{
"range": "^0.2.3",
"versions": "0.2.3\n0.2.9\n0.3.0\n0.2.4-beta.1",
"includePrerelease": false
}{
"matches": [
"0.2.3",
"0.2.9"
],
"unmatched": [
"0.3.0",
"0.2.4-beta.1"
],
"invalid": [],
"minimum": "0.2.3",
"maximum": "0.2.9"
}^0.2.3 keeps releases below 0.3.0-0. The default prerelease gate excludes 0.2.4-beta.1 even though its numeric tuple is between the stable endpoints. The maximum here is 0.2.9 because that is the largest matching input.
Prerelease opt-in for one exact tuple
{
"range": ">=1.2.3-beta.2 <1.3.0",
"versions": "1.2.3-beta.4\n1.2.4-beta.1\n1.2.3",
"includePrerelease": false
}{
"matches": [
"1.2.3-beta.4",
"1.2.3"
],
"unmatched": [
"1.2.4-beta.1"
],
"invalid": [],
"minimum": "1.2.3-beta.4",
"maximum": "1.2.3"
}The range explicitly mentions a prerelease for 1.2.3, so 1.2.3-beta.4 is eligible. The separate 1.2.4-beta.1 tuple is excluded with includePrerelease false. The stable 1.2.3 follows its prerelease in the sorted matches.
Including prereleases still respects boundaries
{
"range": "^1.2.3",
"versions": "1.2.3\n1.3.0-beta.1\n2.0.0-beta.1",
"includePrerelease": true
}{
"matches": [
"1.2.3",
"1.3.0-beta.1"
],
"unmatched": [
"2.0.0-beta.1"
],
"invalid": [],
"minimum": "1.2.3",
"maximum": "1.3.0-beta.1"
}With includePrerelease true, 1.3.0-beta.1 can match ^1.2.3. The expansion still has an upper boundary below 2.0.0-0, so 2.0.0-beta.1 remains unmatched.
Wildcard, invalid rows and stable build ordering
{
"range": "",
"versions": "1.2.3+build.2\n\n1.2.3+build.1\n1.2\n01.2.3\n=1.2.3\n v1.2.4 ",
"includePrerelease": false
}{
"matches": [
"1.2.3+build.2",
"1.2.3+build.1",
"1.2.4"
],
"unmatched": [],
"invalid": [
"1.2",
"01.2.3",
"=1.2.3"
],
"minimum": "1.2.3+build.2",
"maximum": "1.2.4"
}An empty range acts as *. The blank line is skipped, outer spaces and the accepted v prefix normalize away, and incomplete, zero-padded or =-prefixed version rows are invalid. Build suffixes remain visible; build.2 stays before build.1 because equal-precedence rows retain input order.
Excluding one version with OR
{
"range": "<1.2.3 || >1.2.3",
"versions": "1.2.2\n1.2.3+build.7\n1.2.4",
"includePrerelease": false
}{
"matches": [
"1.2.2",
"1.2.4"
],
"unmatched": [
"1.2.3+build.7"
],
"invalid": [],
"minimum": "1.2.2",
"maximum": "1.2.4"
}Two groups express the exclusion without the unsupported != operator. 1.2.3+build.7 has the same precedence as 1.2.3, so it is excluded too. The output is a summary of the submitted versions, not a package-registry query.
Common range-testing mistakes
- Using != as a range operator: use two comparator groups such as <1.2.3 || >1.2.3 instead.
- Pasting package names, tags such as latest, comma-separated lists or incomplete versions into the version list: provide one complete version per line.
- Confusing the hyphen in a prerelease with a hyphen range: write a range with spaces, such as 1.2.3 - 2.0.0.
- Assuming includePrerelease ignores all boundaries, or assuming ^ behaves identically for 0.x and 1.x: inspect the normalized comparator groups.
- Treating the largest matching input as a registry lookup, a compatibility guarantee or a security recommendation: this tool performs none of those checks.
Limits and notes
- Uses pinned node-semver 7.8.5 with loose: false and no version coercion. Supports ^, ~, <, <=, >, >=, =, hyphen ranges, x/X/* wildcards and ||. npm strict syntax is not a pure SemVer-spec validator: a leading v is accepted on version rows, while a leading = is accepted as a range comparator but not on version rows. Partial versions are allowed in ranges, not as individual version entries. != is unsupported; exclude 1.2.3 with <1.2.3 || >1.2.3.
- Without includePrerelease, a prerelease needs a comparator with a prerelease on the same major.minor.patch tuple in the matching comparator group. Enabling the switch removes that default exclusion, but the range boundaries still apply. It does not make every prerelease match, and it can change the normalized comparator expansion.
- A range is limited to 2,000 characters, 32 || groups and 128 whitespace-separated tokens. Version input is limited to 100,000 characters and 1,000 physical lines, including blank lines. Each trimmed version is limited to 256 characters. Oversized version rows are marked invalid; an invalid range or a range/list limit stops the check instead of returning partial matches.
- Sorting uses SemVer precedence and retains build metadata in normalized matches. Equal-precedence entries, including duplicates and different +build suffixes, keep their input order. Minimum and maximum come only from matching input rows; they are not registry releases or the theoretical bounds of the range. No matching rows means both are null.
- Checking is browser-local and can run offline after the page and its bundled code have loaded. No package registry, installed dependency tree or package code is consulted. Matching says nothing about API compatibility, dependency resolution, maintenance or security. Exported JSON includes the entered range and trimmed version rows, including invalid entries; review project information before sharing. Copied or downloaded reports remain outside the page’s control.
Frequently asked questions
Why does ^0.2.3 reject 0.3.0?
For a complete caret range, node-semver allows changes to the right of the first nonzero component. ^0.2.3 expands to >=0.2.3 <0.3.0-0, while ^0.0.3 expands to >=0.0.3 <0.0.4-0. This is a range rule, not a promise that allowed releases are compatible.
Why is a prerelease outside the range even when its number looks high enough?
The default prerelease gate is separate from ordinary numeric comparison. For example, >=1.2.3-beta.2 <1.3.0 admits 1.2.3-beta.4 but excludes 1.2.4-beta.1 unless includePrerelease is enabled. A toggle does not override a comparator boundary, so inspect both the option and the normalized groups.
What is the difference between invalid and unmatched?
An invalid row cannot be parsed as a complete version under these strict npm rules, or exceeds the per-version length limit. An unmatched row is a valid version that fails the range or prerelease rules. For example, 1.2 and 01.2.3 are invalid version rows; 2.0.0 is valid but unmatched by ^1.2.3.
Does build metadata affect sorting or the displayed minimum and maximum?
No. 1.2.3+build.2 and 1.2.3+build.1 have equal precedence, so both are retained in their input order. Minimum is the first sorted matching row and maximum is the last. These values describe your list only, including that stable tie order, and do not look up an earliest or latest published release.