# Semver Range Tester > Test whether a version satisfies a semver range, and why. Handles caret, tilde, x-ranges, hyphen ranges and npm's prerelease rule. Runs in your browser. Source: https://www.revquix.com/tools/semver-checker Cost: free, no signup --- Does a caret range match that version? The answer, and the reason - including the two rules almost nobody holds with confidence: caret on a zero-major, and why a release candidate is excluded. ## At a glance - Takes: A version and a range - caret, tilde, comparators, x-ranges or hyphens - Returns: Whether it matches, why, and what the range expands to - Handles: The zero-major caret rule and npm’s prerelease exclusion - Privacy: Runs in your browser - nothing you paste is uploaded ## The two rules people get wrong A caret allows changes that do not modify the leftmost non-zero part of the version. On a released package that means the major is pinned, which everybody knows. On a zero-major package it means the minor is pinned - so a caret on a zero-point-two release behaves exactly like a tilde, and will not accept the next minor. That is not a footnote. Every pre-1.0 dependency in a lockfile is governed by it, and it is the single most surprising behaviour in the system. A caret on a zero-zero-x version is narrower still: it accepts nothing but that exact version. The second rule is prereleases. A release candidate does not satisfy an ordinary range even when it falls inside the numeric window, because a prerelease only qualifies if the range itself names a prerelease at the same major, minor and patch. That is why an install can refuse a version that looks obviously in range, and the tool says so explicitly rather than returning a bare no. ## What it accepts The range grammar npm evaluates a manifest against, which is the one most people mean when they say semver range. - Caret and tilde, including the two-part and one-part spellings - Comparators - greater than, less than, and their inclusive forms - x-ranges and the bare asterisk - Hyphen ranges, inclusive at both ends, with an open upper bound - Alternatives joined by a double pipe, evaluated as a union ## Why the answer comes with a reason A boolean answers the literal question and leaves you no better informed the next time. Every verdict here carries the expansion of the range into comparators and a sentence explaining the outcome, so the rule is learnable rather than merely applied. Below the verdict is a table of the comparisons that catch people out, each row a real behaviour rather than a simplification. ## What it will not do This is npm’s interpretation, which is what a package manifest is evaluated against. Other ecosystems differ in places that matter - most notably Cargo, where a bare version is treated as a caret range by default, and Go modules, which use minimal version selection rather than range resolution at all. It also does not resolve a dependency tree. Whether an upgrade is safe depends on transitive constraints, peer dependencies and what your lockfile already pins, none of which a single version and a single range can express. ## Questions people ask ### Why does a caret range reject the next minor version? Because the package is on a zero major. A caret pins the leftmost non-zero part, so on a zero-point-x version that is the minor rather than the major, and the range behaves like a tilde. It is the correct behaviour and the one that surprises people most often, since almost every pre-1.0 dependency is governed by it. ### Why is my release candidate excluded from a range it clearly falls inside? Because of the prerelease rule. A prerelease only satisfies a range when the range itself names a prerelease at the same major, minor and patch - otherwise a caret on a one-point-oh would silently accept a two-point-oh alpha, which is a breaking version by definition. Name a prerelease explicitly in the lower bound to opt in. ### What is the practical difference between caret and tilde? On a released package, a caret allows new minor versions and a tilde allows only new patches. So a caret takes bug fixes and new features, and a tilde takes bug fixes alone. On a zero-major package the two behave identically, which is why the distinction matters less than people assume for young dependencies. ### Does build metadata affect whether a version matches? No. Metadata after a plus sign is parsed and then ignored for every comparison, exactly as the specification requires - two versions differing only in build metadata are equal. Prerelease identifiers after a hyphen are the opposite: they participate fully in ordering, and a prerelease sorts below the release of the same triple. ### Does this apply to Cargo, Composer or Go modules? Only loosely. This implements the range grammar npm uses, which Composer follows closely. Cargo treats a bare version as a caret range by default, and Go modules use minimal version selection rather than resolving ranges at all - so check the tool against your own ecosystem before relying on an answer.