What is the structure of a semver string?

Semantic Versioning is MAJOR.MINOR.PATCH, for example 2.4.1. An optional pre-release follows a hyphen (1.0.0-beta.2) and optional build metadata follows a plus sign (1.0.0+build.5). This tool builds each part to that exact grammar.

Are pre-release identifiers ordered correctly?

Pre-release tags use the conventional dot-separated form like alpha.1, beta.3 or rc.2. Per the spec these mark a version as lower precedence than the same version without a pre-release, which is why 1.0.0-rc.1 sorts before 1.0.0.

What is build metadata used for?

Build metadata after a plus sign (for example +20260606 or +sha.a1b2c3) is informational only. Semver explicitly ignores it when comparing precedence, so 1.0.0+x and 1.0.0+y are considered equal versions.

Can I generate many versions at once?

Yes. Set a count to produce a list of independent version strings. This is handy for seeding a registry, building a dropdown of fake releases, or stress-testing a version parser.

Does the tool send data anywhere?

No. Every version is generated locally in your browser with no network calls, so you can use it offline and nothing you produce is transmitted to a server.

Semantic Version Generator

Generate spec-compliant version strings

The Semantic Version Generator produces version strings that follow the semver.org grammar exactly: a MAJOR.MINOR.PATCH core, an optional pre-release after a hyphen, and optional build metadata after a plus sign. Use it to seed a package registry, populate a release dropdown, or feed a parser realistic input during testing.

How it works

A semantic version has three required numeric components separated by dots. The tool draws each of major, minor and patch as a non-negative integer inside the range you choose. When the pre-release option is on, it appends a hyphen followed by an identifier such as alpha, beta or rc and a dot-numbered counter — for example -beta.2. When build metadata is on, it appends a plus sign and a short token such as a date or a fake commit hash.

Precedence rules matter: per the spec, a version with a pre-release has lower precedence than the same core version without one, and build metadata is ignored entirely for comparison. The generated strings respect that grammar so they parse cleanly in tools like npm, Cargo, or any ^semver library.

Tips and example

A plain release looks like 3.7.0. A pre-release looks like 3.7.0-rc.1. A fully decorated string looks like 3.7.0-rc.1+build.42.
Keep major at 0 to model pre-1.0 software, where the public API is considered unstable.
Build metadata never affects ordering, so use it only for traceability such as a date stamp or short hash.
All values are synthetic — never treat a generated version as the real release number of any real package.