Home›Validators›Data›SemVer Validator

SemVer Validator

Data

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

Reviewed by the thecalcu.com team · Last updated July 3, 2026

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.

Why Use a SemVer Validator?

Version strings are written by hand, generated by CI/CD scripts, read from package.json or Cargo.toml, and passed to deployment tools, at every step there are opportunities for subtle formatting errors that downstream tooling silently rejects or misparses.

Developer use case: An Indian SaaS team is publishing an npm package to a private registry. The build script auto-generates version strings from a date-based format and the release intermittently fails with a cryptic registry error. Pasting a few generated versions into the validator immediately reveals that the day-of-month is zero-padded (1.0.07), a leading zero that violates SemVer and causes the registry to reject the manifest.

DevOps use case: A Helm chart version field is being populated from a CI environment variable. Pasting the resulting string into the validator catches that the pre-release identifier contains a space (injected from a poorly formatted git commit message), which produces a SemVer parse error in Helm's version resolution.

Who Should Use This Validator?

Backend and DevOps engineers publishing packages to npm, PyPI, Cargo, or internal registries who need to confirm their release automation produces correctly formatted version strings before they hit the registry.

Platform engineers managing Helm chart repositories or Kubernetes operator manifests where version fields must be SemVer-parseable for upgrade path detection.

Open-source maintainers checking CHANGELOG or release notes version strings before tagging, especially useful when pre-release identifiers or build metadata are being used for the first time. Pair with the JSON Validator when validating a full package.json file.

Tech leads reviewing PRs where a version bump is included, paste the new version into the validator to confirm it is structurally correct and follows the expected increment type (MAJOR for breaking changes, MINOR for features, PATCH for fixes).

What Insights Does the SemVer Validator Give You?

The validator returns a Valid or Invalid badge plus a structured breakdown.

On a valid version string:

  • The MAJOR, MINOR, and PATCH components are displayed individually, confirming the parser read them as intended
  • Any pre-release identifier and build metadata label are shown separately, useful for confirming that a hyphen-containing pre-release like rc.1 was parsed as pre-release and not as a component separator

On an invalid version string:

  • The specific rule violated is named, e.g. "MINOR '01' has a leading zero" or "missing components: found 2, expected 3"
  • Multiple violations are listed as separate items so all errors are visible at once
  • For v-prefixed strings in strict mode, the error message shows the corrected string (e.g. "try '1.2.3' instead of 'v1.2.3'")

Scope: This validator checks format only. It cannot determine whether the version represents a valid upgrade path from the previous version, whether the increment type matches the nature of the changes, or whether the version exists in any registry.

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.
Show formula & methodology ↓Show less ↑

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

What is SemVer (Semantic Versioning)?
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.
What is the full SemVer 2.0.0 format?
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.
What is the difference between a pre-release version and build metadata?
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.
Why does the validator reject versions with a 'v' prefix like v1.0.0?
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.
What makes a SemVer version invalid?
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.
How do version comparison rules work in SemVer?
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.
Is the SemVer Validator checking my package version against a real registry?
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.
Is my version string stored or sent anywhere?
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.
How do I use the SemVer Validator?
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.
Which tools and package managers require SemVer?
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.
What is the difference between SemVer 1.0.0 and SemVer 2.0.0?
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