Home›Validators›Data›SemVer Validator

SemVer Validator

Data

Validate semantic version strings against the SemVer 2.0.0 spec instantly. Checks MAJOR.MINOR.PATCH, pre-release identifiers, and build metadata — client-side only.

What is a SemVer?

The SemVer Validator checks whether a version string conforms to the Semantic Versioning 2.0.0 specification — the standard versioning scheme used by npm, Cargo, Helm, Composer, and most modern package managers and release pipelines.

A valid SemVer string follows the pattern MAJOR.MINOR.PATCH[-PRERELEASE][+BUILDMETADATA], where:

  • MAJOR — incremented for breaking, backward-incompatible API changes
  • MINOR — incremented for new backward-compatible functionality
  • PATCH — incremented for backward-compatible bug fixes
  • Pre-release (optional) — appended after -: 1.0.0-alpha, 2.3.0-rc.1
  • Build metadata (optional) — appended after +: 1.0.0+build.20241231

Each of MAJOR, MINOR, and PATCH must be a non-negative integer with no leading zeros — 01.0.0 and 1.00.0 are structurally invalid under the spec. This rule is the most frequent source of format violations in auto-generated version strings from build pipelines.

The validator detects: missing components (1.0 → needs 1.0.0), leading zeros, invalid pre-release or build metadata identifiers, and the presence of a v prefix (which git tags use but SemVer itself does not include). A lenient mode strips the v before validating, for teams that store versions as git tag names.

Use the Regex Validator if you need to test a custom version pattern that deviates from SemVer. For UUID format validation, which follows a similarly strict structure, see the UUID Validator.

All validation runs client-side. Your version strings are never sent to any server or stored in any form.

How to use this SemVer calculator

  1. Type or paste your version string into the "Version String" input field. Examples: 1.0.0, 2.3.4-alpha.1, 1.0.0-beta+exp.sha.5114f85.
  2. Select the v-prefix handling mode — "Strict" (default) rejects any string starting with v or V; "Lenient" strips the prefix before validating, for git tag-style versions like v1.2.3.
  3. Check the Valid/Invalid badge — it updates instantly as you type. A green "Valid" badge means the string conforms to SemVer 2.0.0.
  4. Read the details panel — on success, the parsed components (MAJOR, MINOR, PATCH, pre-release, build) are listed; on failure, the specific rule violations are enumerated.
  5. Fix violations based on the details — leading zeros are the most common fix (remove the zero); missing PATCH is the second most common (add .0 to complete the triple).
  6. Re-validate after correcting the string — confirm all details lines show parsed components, not error hints.

Formula & Methodology

SemVer 2.0.0 format rule:

version ::= MAJOR "." MINOR "." PATCH ["-" prerelease] ["+" buildmeta] MAJOR   ::= numeric-identifier MINOR   ::= numeric-identifier PATCH   ::= numeric-identifier numeric-identifier ::= "0" | positive-digit | positive-digit digits positive-digit     ::= "1"-"9" digits             ::= digit | digits digit prerelease ::= dot-separated-pr-identifiers buildmeta  ::= dot-separated-build-identifiers

Key invariants enforced:
- MAJOR, MINOR, PATCH must be non-negative integers — no leading zeros except for the bare value 0
- Pre-release identifiers may be numeric (no leading zeros) or alphanumeric+hyphen
- Build metadata identifiers may contain alphanumerics and hyphens (leading zeros permitted here per spec)
- Empty identifiers (e.g. 1.0.0- or 1.0.0+) are invalid

Official regex (SemVer 2.0.0):

^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*) (?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)     (?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?  (?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$

Valid and invalid examples:

| Version string | Valid? | Note |
|---|---|---|
| 1.0.0 | ✓ | Canonical form |
| 0.0.1 | ✓ | Early development |
| 1.2.3-alpha.1 | ✓ | Pre-release |
| 1.0.0-beta+exp.sha.abc | ✓ | Pre-release + build metadata |
| 1.0 | ✗ | Missing PATCH component |
| 01.0.0 | ✗ | Leading zero in MAJOR |
| 1.0.0.0 | ✗ | Four components — SemVer has exactly three |
| v1.0.0 | ✗ strict / ✓ lenient | v prefix is a git convention, not SemVer |
| 1.0.0- | ✗ | Empty pre-release identifier |

Use the UUID Validator for RFC 4122 UUID format validation, which follows a similarly strict structural specification.

Frequently Asked Questions

Semantic Versioning (SemVer) is a versioning scheme for software where the version number communicates specific meaning about what changed between releases. A SemVer string takes the form MAJOR.MINOR.PATCH, where MAJOR increments signal breaking changes, MINOR increments signal new backward-compatible features, and PATCH increments signal backward-compatible bug fixes. The specification was created by Tom Preston-Werner and is published at semver.org.
The full SemVer 2.0.0 format is MAJOR.MINOR.PATCH[-PRERELEASE][+BUILDMETADATA]. MAJOR, MINOR, and PATCH are non-negative integers with no leading zeros. An optional pre-release version can be appended after a hyphen — for example 1.0.0-alpha.1 or 2.3.0-rc.2. An optional build metadata label can follow a plus sign — for example 1.0.0+20241231 or 1.0.0-beta+exp.sha.5114f85.
A pre-release identifier (after -) indicates an unstable release with lower precedence than the associated normal version — 1.0.0-alpha is lower precedence than 1.0.0. Build metadata (after +) carries information about the build environment (commit hash, build date, CI run number) and does NOT affect version precedence — 1.0.0+build.1 and 1.0.0+build.2 are treated as equivalent when comparing versions. In practice, build metadata is most useful in CI/CD pipelines and package registries.
The SemVer 2.0.0 specification states that the version string itself starts with the MAJOR integer — the 'v' prefix is a git tag convention, not part of SemVer. Tools like npm, Cargo, and PyPI strip the 'v' before parsing the version. By default this validator enforces strict SemVer, but you can switch to 'Allow v-prefix' mode in the dropdown to validate git tag-style strings like v1.2.3.
Common SemVer violations include: fewer than three dot-separated components (1.0 is invalid, 1.0.0 is required); leading zeros in numeric identifiers (01.0.0 and 1.00.0 are invalid); a 'v' prefix in strict mode; empty pre-release or build metadata identifiers (1.0.0- and 1.0.0+ are invalid); and spaces, underscores, or non-alphanumeric characters in identifiers other than hyphen and dot.
Versions are compared left-to-right: MAJOR first, then MINOR, then PATCH. A higher number in any field means a higher version when all fields to its left are equal — so 2.0.0 > 1.9.9. Pre-release versions have lower precedence than the associated normal version: 1.0.0-alpha < 1.0.0. Pre-release identifiers are compared field by field: numeric identifiers compare numerically, alphanumeric identifiers compare lexicographically, and numeric identifiers always have lower precedence than alphanumeric ones.
No — the validator only checks whether the version string conforms to SemVer 2.0.0 format rules. It does not contact npm, PyPI, RubyGems, or any other package registry. It cannot tell you whether that version has been published, or whether a newer version exists. The check is purely structural — correct integer components, no leading zeros, valid pre-release and build metadata identifiers — and runs entirely in your browser.
No — all validation happens client-side using JavaScript running in your browser. Your version string is never sent to any server, stored, or logged. The page validates offline once loaded. This applies whether you are checking a public npm package version or an internal service version from a private build.
Type or paste your version string into the 'Version String' field. Select strict mode (default, rejects 'v' prefix) or lenient mode (strips 'v' before validating) from the dropdown. The Valid/Invalid badge updates instantly. If invalid, the details panel shows which specific rule was violated — missing components, leading zeros, or malformed pre-release identifiers — so you can fix the version string immediately.
npm (Node.js), Cargo (Rust), Composer (PHP), Helm (Kubernetes), and most modern dependency managers require SemVer-compatible version strings. Dependency resolution in these tools relies on SemVer's predictable increment rules to determine whether an upgrade is safe — a PATCH increment is presumed safe; a MAJOR increment requires developer review. Indian SaaS and fintech teams building microservices or publishing npm/PyPI packages benefit directly from SemVer-compliant versioning.
SemVer 2.0.0 clarified and extended the original specification in several important ways: it introduced build metadata (the + field, absent in 1.0.0), clarified that build metadata does not affect version precedence, specified that pre-release identifiers are compared field-by-field with defined type rules (numeric vs alphanumeric), and prohibited leading zeros in numeric identifiers. Most modern package managers implement SemVer 2.0.0 rules. This validator checks against the 2.0.0 specification.
Also known as
check semantic versionsemver format checkerversion string validatornpm version validatorpackage version check