/^/
HardProgramming6 min read

Semantic Version (SemVer) Regex

Validates a full Semantic Versioning 2.0.0 string, including major.minor.patch, optional prerelease identifiers, and optional build metadata, matching the official semver.org grammar.

#semver#versioning#npm#release#validation#regex

Regex Pattern

^(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-]+)*))?$

Pattern Breakdown

Hover over a token to see what it does.

^(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-]+)*))?$
TokenMeaning
(0|[1-9]\d*)A version number component (major, minor, or patch) that is either exactly 0 or a positive integer with no leading zeros
\.Literal dot separating the major, minor, and patch components
(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?Optional prerelease section: a hyphen followed by one or more dot-separated alphanumeric identifiers (e.g. -alpha.1)
(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?Optional build metadata section: a plus sign followed by one or more dot-separated alphanumeric identifiers (e.g. +build.42)
$Anchors the match to the end of the string

Detailed Explanation

What it does

This pattern validates that a string is a fully compliant Semantic Versioning 2.0.0 identifier: three dot-separated non-negative integers (major.minor.patch) with no leading zeros, an optional prerelease label introduced by a hyphen, and optional build metadata introduced by a plus sign.

Why it works

Each of the three core version numbers uses (0|[1-9]\d*) to allow zero or a number with no leading zeros, matching the SemVer spec's rule against leading zeros like '01'. The optional prerelease group starts with a literal hyphen and accepts one or more dot-separated identifiers, each of which is either a numeric identifier without leading zeros, or an alphanumeric identifier that may contain hyphens and leading zeros (since non-numeric identifiers are compared lexically, not numerically). The optional build metadata group starts with a literal plus and accepts freely formed alphanumeric/hyphen identifiers, since build metadata is ignored when determining version precedence. This is the same pattern published on semver.org's official regex reference.

Common use cases

  • Validating package.json 'version' fields in build tooling or linters
  • Parsing release tags in CI/CD pipelines to confirm they follow SemVer before publishing
  • Enforcing consistent version strings in Git tags or Docker image tags
  • Building a version-comparison or dependency-resolution library that first needs to confirm well-formed input

Edge cases

  • A prerelease version like '1.0.0-alpha.1' or '1.0.0-0.3.7' is accepted since prerelease identifiers can mix numeric and alphanumeric segments
  • Build metadata is accepted independently of or combined with a prerelease tag, e.g. '1.0.0-beta+exp.sha.5114f85'
  • Leading zeros in core version numbers, such as '1.01.0', are correctly rejected per the SemVer spec
  • A version missing the patch component, like '1.0', is rejected since all three components are mandatory
  • A 'v' prefix, common in Git tags (e.g. 'v1.0.0'), is not part of the SemVer spec and is correctly rejected; strip it before validating if your tagging convention includes it

Limitations

  • Does not accept a leading 'v' prefix commonly used in Git tags; callers must strip it first if needed
  • Does not compare or order two version strings by precedence; it only validates structural correctness
  • The prerelease and build metadata capture groups can be large for deeply segmented identifiers, though this rarely matters in practice for typical version strings
  • Does not enforce any application-specific maximum on major/minor/patch magnitude beyond what the SemVer grammar itself allows

Interactive Tester

Edit the pattern or text below — matching runs live in your browser.

//
Open in Playground →
1.0.0 1.0.0-alpha 1.0.0-alpha.1

Test Cases

Editable — add your own inputs to see if they pass.

InputExpectedResult
Pass
Pass
Pass
Pass
Pass
Pass
Pass
Pass
Pass
Pass

Language Variants

Production-ready examples in 12 languages.

const semverRegex = /^(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-]+)*))?$/;
console.log(semverRegex.test('1.0.0-alpha.1')); // true

Common Mistakes

Writing a loose pattern like ^\d+\.\d+\.\d+$ that ignores prerelease and build metadata entirely, rejecting valid versions like '1.0.0-rc.1'

Fix: Include the optional prerelease and build metadata groups so fully compliant SemVer strings are accepted

Allowing leading zeros in version numbers, such as '1.02.0', which violates the SemVer spec

Fix: Use (0|[1-9]\d*) for each numeric component instead of a plain \d+ to reject leading zeros

Forgetting to strip a 'v' prefix from Git tags before validating, causing every tag to fail

Fix: Strip or optionally match a leading 'v' in the calling code, since 'v' is a Git tagging convention, not part of the SemVer grammar itself

Performance Notes

  • The official SemVer regex is more complex than most patterns but remains linear-time in practice since its alternations don't overlap ambiguously for well-formed input
  • Precompile the regex once per process rather than rebuilding it per validation call, especially in CI pipelines validating many tags
  • For extremely high-throughput version parsing, a dedicated hand-written parser can outperform the regex, but the regex is more than fast enough for typical build-tool usage

Browser Compatibility

EngineSupportedNotes
ChromeYes—
FirefoxYes—
SafariYes—
EdgeYes—
Node.jsYes—