Semver satisfies
Exactsemver_satisfiesDeterministic and authoritative — the canonical answer for this input.
Check whether a version satisfies an npm-style range expression. Supports ^, ~, <, <=, >, >=, =, !=, hyphen ('a - b'), wildcards (x, X, *), space/comma-joined AND clauses, and '||' for OR. Returns satisfies boolean and the matched clause when true. Processing multiple inputs? Use `semver_satisfies_batch` to do up to 1000 in one call.
Parameters
versionstringrequiredVersion to test.
rangestringrequirednpm-style range expression. Supports ^, ~, <, <=, >, >=, =, !=, hyphen (a - b), wildcards (x, X, *), space/comma-joined AND clauses, and `||` OR.
Call it
curl -X POST https://api.snipget.ai/v1/semver/satisfies \
-H "Authorization: Bearer sk_live_..." \
-H "Content-Type: application/json" \
-d '{"version":"1.5.0","range":"^1.2.0"}'The Batch tab sends up to 1000 inputs in one call via /v1/semver/satisfies/batch.
Example response
{
"is_valid": true,
"version": "1.5.0",
"range": "^1.2.0",
"satisfies": true,
"matched_clause": [
">=1.2.0",
"<2.0.0"
]
}FAQ
What does this tool answer?
It tells you whether one specific version falls inside a range of allowed versions. For example, does 1.5.0 satisfy "^1.2.0"? The answer here is yes, because the caret range allows anything from 1.2.0 up to but not including 2.0.0.
Why not just eyeball whether a version is in range?
Range expressions like ^, ~, and hyphen ranges have precise, non-obvious rules about which versions they include. Getting the upper bound wrong is a common mistake. This tool evaluates the range exactly the way package managers like npm do, so you do not have to memorize the rules.
Which range styles are supported?
The npm-style operators: caret (^), tilde (~), the comparisons <, <=, >, >=, =, and !=, hyphen ranges like "1.0.0 - 2.0.0", wildcards (x, X, *), space or comma joined AND clauses, and || for OR.
Is the yes/no answer authoritative?
Yes. It is exact and deterministic, the same canonical answer every time for the same version and range. The result also includes matched_clause showing exactly which part of the range the version matched.
How are pre-release versions like 1.0.0-beta handled?
By the npm rule: a pre-release only satisfies a range if the range itself names a pre-release on the same major.minor.patch. This prevents a beta from sneaking into a range meant for finished releases. Invalid versions or ranges return confidence 0 with a reason rather than an error.