ForHosting KIT · Developer Utilities

SemVer version parser

Split a version such as 1.2.3-alpha.1+build.7 into major 1, minor 2, patch 3, prerelease alpha.1 and build build.7, checked strictly against SemVer 2.0.0. A malformed tag is rejected with the rule it breaks. Free in your browser.

  • Free
  • Runs in your browser
  • No sign-up
  • Your data stays on your device
Use it from WebAPIEmailTelegramApp soon
If you enter
Text
1.2.3-alpha.1+build.7
You get
Version
1.2.3-alpha.1+build.7
Major
1
Minor
2
Patch
3

Semantic Versioning (SemVer 2.0.0) is the version grammar used by npm packages, Rust crates, Go modules, and most public APIs. A version is not just three numbers: optional hyphenated prerelease identifiers and plus-prefixed build metadata change how a release is labeled and compared. This SemVer version parser accepts a single version string, validates it strictly against the official SemVer 2.0.0 specification, and returns the numeric major, minor, and patch components together with any prerelease and build identifiers.

What SemVer 2.0.0 actually allows

Semantic Versioning 2.0.0 defines a version as MAJOR.MINOR.PATCH, three non-negative integers joined by dots, with optional hyphenated prerelease identifiers and optional plus-prefixed build metadata. Each of major, minor, and patch is a numeric identifier: either a single zero or a digit from one to nine followed by more digits, so 1.0.0 is valid and 01.0.0 is not. A prerelease version is the core followed by a hyphen and one or more dot-separated identifiers such as alpha, rc.1, or 0.3.4.

A prerelease identifier is either a numeric identifier with the same no-leading-zero rule, or an alphanumeric identifier that contains at least one letter or hyphen and otherwise only ASCII letters, digits, and hyphens. Build metadata follows a plus sign and uses the same identifier alphabet, except that all-digit build identifiers may keep leading zeros, so 1.0.0+001 is legal. Empty identifiers, consecutive dots, a trailing hyphen or plus, a leading v, two-part versions such as 1.2, and non-ASCII letters are all illegal.

This parser implements that grammar as a left-to-right scanner rather than a permissive regular expression, so a failure names the rule that was broken instead of returning a half-parsed object. Comparison order is out of scope: the capability parses and validates, it does not rank two versions against each other.

Where a SemVer version parser earns its keep

Package registries, release bots, and changelog generators need a single place that answers whether a tag is a legal SemVer version and what its five parts are. A continuous-integration job that refuses to publish when the git tag is v1.2.3 instead of 1.2.3, or when someone typed only 1.2, saves a broken release before it reaches a registry. Dependency scanners that ingest lockfiles want structured major, minor, patch, and prerelease fields without pulling a full language-specific semver runtime into an edge worker.

Curriculum authors teaching versioning want a dedicated landing that explains leading zeros and build metadata rather than burying the topic under a generic string splitter. Failed validation does not consume balance. Keep strings under the documented length limit, pin the structured fields in tests, and you get reproducible components for release tooling, learning-management plugins, and edge workers without standing up a language-specific semver library of your own.

Validate git tags before a release

Reject a publish job when the tag is v1.2.3, 1.2, or 01.0.0 instead of a legal SemVer 2.0.0 version.

Split versions in a lockfile or SBOM

Turn each dependency version into major, minor, patch, prerelease, and build fields for scanners and dashboards.

What is a valid SemVer 2.0.0 version string?

MAJOR.MINOR.PATCH with optional -prerelease and +build, using only ASCII letters, digits, and hyphens. Example: 1.2.3-alpha.1+build.7. Two-part versions and a leading v are not valid.

Does the parser accept a leading v, such as v1.2.3?

No. SemVer 2.0.0 does not allow a v prefix.

Why is 01.0.0 rejected?

Numeric identifiers must not have leading zeros. 0 is allowed as a whole identifier (0.1.0), but 01 is not. The same rule applies to numeric prerelease identifiers such as 01 in 1.0.0-01.

How are prerelease and build returned when they are absent?

Those keys are omitted, never set to null.

Can build metadata keep leading zeros?

Yes. After the plus sign, an all-digit build identifier may keep leading zeros, so 1.0.0+001 is legal. Major, minor, patch and numeric prerelease identifiers may not.

Can it tell me which of two versions is newer?

No. It parses and validates one version at a time and does not rank versions against each other. When you need to sort or compare, use the structured parts it returns in your own tools.

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

POSThttps://api.kit.forhosting.com/dev/semver-parse

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.

curl -X POST https://api.kit.forhosting.com/dev/semver-parse \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"1.2.3-alpha.1+build.7"}'
{
  "text": "1.2.3-alpha.1+build.7"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.semver_parse",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

max_chars256
HTTPCodeMeaning
401unauthorizedMissing or invalid API key.
402insufficient_balanceYour balance doesn't cover the task price.
404unknown_typeThat task type doesn't exist.
429rate_limitedToo many requests. Use the webhook instead of polling.

Leading v prefixes, missing patch numbers, leading zeros on numeric identifiers, empty identifiers, and non-ASCII characters are rejected with invalid_input rather than silently rewritten.

Input contract, response shape, and error behaviour

Surrounding whitespace is trimmed; the remaining string must be a complete SemVer 2.0.0 version. Do not send a leading v, a range operator, or a two-part shorthand. POST a JSON body with the required string field text (aliases version, semver, value). On success the body echoes version as the trimmed input, major, minor, and patch as safe integers, core as the MAJOR.MINOR.PATCH substring, and is_prerelease as a boolean. When a prerelease section is present, prerelease is the hyphen-free identifier string and prerelease_identifiers is the split array; both keys are omitted when there is no prerelease. When build metadata is present, build and build_identifiers appear the same way and are omitted otherwise, so clients never see null. Example: 1.2.3-alpha.1+build.7 yields major 1, minor 2, patch 3, prerelease alpha.1, build build.7, and is_prerelease true. Missing text, an empty string, a string longer than two hundred and fifty-six characters, a number instead of a string, leading zeros on major, minor, patch, or a numeric prerelease identifier, illegal characters, leftover characters after the version, and a leading v all fail with invalid_input and an English message that names the field or the broken rule. Those failures are not billed. Successful API pricing is the published base of $0.002 per item.

Teach the SemVer grammar

Show students which strings the specification accepts and which it rejects, with the same rules the API enforces.

What does the SemVer version parser cost?

The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.

Read the full KIT documentation →