SemVer range satisfies checker

This checker evaluates that question with deterministic SemVer precedence. It understands comparison operators, whitespace intersections, hyphen ranges, wildcard and partial versions, and double-pipe alternatives. Prerelease and build identifiers receive their proper semantic meaning, so the result is suitable for dependency tooling rather than a rough numeric comparison.

Write a version and the range you need to test

Provide one complete semantic version such as <code>2.4.1</code> and one range expression. A whitespace-separated comparator set means every comparator must pass, so <code>&gt;=2.0.0 &lt;3.0.0</code> accepts stable releases from major version two. Separate sets with <code>||</code> when either branch may pass. An exact version is also a valid range. The checker returns the normalized version, the trimmed range, a boolean result, and the one-based alternative that matched; zero means no alternative matched. This explicit result shape makes the capability easy to place in a deployment guard, dependency report, manifest editor, or test fixture without parsing prose. Inputs are deliberately strings because converting versions to floating-point numbers would make 1.10 appear smaller than 1.9 and would discard prerelease information. A leading <code>v</code> on a complete version is accepted and normalized away, while malformed numeric components, empty alternatives, and invalid identifiers produce a typed input error instead of an unreliable false result.

Use comparators, hyphen ranges, and wildcards precisely

Comparators may use <code>&gt;</code>, <code>&gt;=</code>, <code>&lt;</code>, <code>&lt;=</code>, or <code>=</code>. Multiple comparators in one alternative form an intersection. A hyphen expression such as <code>1.2.3 - 2.4.0</code> includes both complete endpoints, while a partial upper endpoint expands to the end of that component family: <code>1.2 - 2.4</code> begins at 1.2.0 and stops before 2.5.0. Wildcards may be written as <code>x</code>, <code>X</code>, or <code>*</code>. Thus <code>3.x</code> covers stable 3.0.0 through versions below 4.0.0, and the partial range <code>3.2</code> behaves like <code>3.2.x</code>. Wildcards must trail known components; an expression such as <code>1.x.4</code> is rejected because it does not describe a coherent interval. Caret and tilde shorthand are intentionally rejected by this capability. Express those boundaries with explicit comparators so the evaluated rule remains visible and unambiguous in logs, generated policies, automated checks, and human reviews.

Understand precedence, prereleases, and build metadata

Semantic versions are compared component by component, not alphabetically. Major, minor, and patch numbers decide first. A prerelease has lower precedence than the corresponding stable release, and its dot-separated identifiers are compared from left to right: numeric identifiers compare numerically, numeric identifiers sort before nonnumeric ones, and a shorter equal prefix sorts first. Build metadata after <code>+</code> is preserved in the normalized output but never changes precedence, as required by SemVer. Dependency managers also protect users from accidentally selecting prereleases. This checker follows that behavior: a prerelease can satisfy a comparator set only when that same set contains a prerelease comparator with the identical major, minor, and patch tuple. For example, <code>2.0.0-beta.2</code> may satisfy <code>&gt;=2.0.0-beta.1 &lt;2.0.0</code>, but it does not enter a broad wildcard merely because its numeric core fits. Every evaluation is local and deterministic. No registry is queried, no package is downloaded, and no current release is guessed, so repeated calls with the same strings return the same decision.