About this semver checker
Version numbers look trivial until they go wrong, and then they go wrong in ways that break software for thousands of people. Semantic Versioning, usually shortened to SemVer, is the agreement that stops that happening: a version number is not a marketing label but a contract, with three numbers that each promise something specific about compatibility. A semantic version checker takes a version string and tells you whether it follows the rules, what each part means, how two versions compare, and what the next version should be after a given kind of change. For anyone who publishes a library, maintains an API, or merely tries to understand why an update broke their project, that contract is essential knowledge.
The SemVer format is MAJOR.MINOR.PATCH, three non-negative integers separated by dots, with no leading zeroes, optionally followed by a prerelease tag after a hyphen and build metadata after a plus sign. The rules for incrementing are the heart of the system: increase the major number when you make an incompatible change, increase the minor number when you add functionality in a backwards-compatible way, and increase the patch number for backwards-compatible bug fixes. A prerelease version, such as 2.0.0-beta.1, signals that the release is not yet stable and may change, and it always sorts before the release it precedes, so 1.0.0-alpha is less than 1.0.0. Build metadata, such as +build.5, is ignored when comparing precedence, which surprises many people the first time they meet it.
Using the tool covers the three jobs version numbers actually do. The checker parses a version and reports whether it is valid SemVer, breaking it into major, minor, patch, prerelease, and build parts, so an invalid string fails with an explanation rather than silently passing. The comparison panel takes two versions and tells you which is newer, applying the full precedence rules, including the prerelease ordering that simple string comparison gets wrong. The bump panel takes a base version and produces the next major, minor, or patch version, resetting the lower numbers correctly, which is the step most often fumbled by hand. Together they turn version arithmetic from a source of arguments into a mechanical check.
The comparison rules deserve a worked example, because they contain the subtleties. Comparing 2.0.0 with 1.9.9, the major numbers decide immediately: 2 beats 1, so 2.0.0 is newer regardless of the minor and patch numbers, which is why a major bump is such a strong signal. Comparing 1.0.0-alpha with 1.0.0, the prerelease rule decides: a version with a prerelease tag is always less than the same version without one, so the alpha sorts first. Comparing 1.0.0-alpha.1 with 1.0.0-alpha.beta, numeric identifiers sort before alphanumeric ones, and numeric identifiers compare numerically, so alpha.1 comes first. And comparing 1.0.0+build.1 with 1.0.0+build.2, the answer is that they are equal in precedence, because build metadata is explicitly ignored, a rule that exists so build numbers can vary freely without implying a new release.
Bumping correctly is a discipline as much as an arithmetic operation, and the common mistakes are worth naming. Bumping the minor number without resetting the patch to zero produces versions like 1.3.4 after 1.2.3, which implies a history that never happened. Bumping the major number for a new feature overstates the break and forces every consumer to review a change that would not have hurt them. Failing to bump the major number for a breaking change is the worst error of all, because consumers who trusted the contract will upgrade automatically and break. The tool's bump buttons exist to make the correct operation the easy one: choose the kind of change, and the reset happens automatically, exactly as the specification requires.
The ecosystem around SemVer is what gives it its power. Package managers use version ranges, such as caret and tilde ranges, to decide which updates are safe to install automatically, and those ranges only make sense if publishers honour the contract. Continuous integration pipelines check that a release's version has actually increased, changelogs are organised by version with breaking changes called out at the top, and dependency dashboards flag major bumps for human review precisely because they may break things. When a project follows SemVer honestly, its consumers can automate with confidence; when it does not, every update becomes a manual review, and the cost is paid across the whole ecosystem. The checker on this page is a small part of that discipline, but it is the part that catches errors before they are published.
A few practical habits complete the picture. Start new projects at 0.1.0 or 1.0.0 deliberately: in SemVer, major version zero is explicitly for initial development, where anything may change, and the 1.0.0 release is a public promise that the API is stable. Tag releases in version control with the exact version string, and make the changelog entry for that version part of the release process rather than an afterthought. Never re-release the same version number with different contents, because consumers cache by version and will receive inconsistent artifacts. And when in doubt about whether a change breaks compatibility, bump the major number: it is always safer to overstate a break than to hide one. Version numbers are promises, and this tool exists to help you keep them.
A second worked example, comparing prerelease chains, shows the full subtlety of the precedence rules. Consider 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-alpha.beta, 1.0.0-beta, 1.0.0-beta.2, 1.0.0-beta.11, and 1.0.0-rc.1, which is the exact example sequence from the SemVer specification, in ascending order. Notice that beta.2 comes before beta.11, because numeric identifiers compare numerically rather than as text, so 2 is less than 11 even though the string 11 sorts before 2 alphabetically. Notice too that alpha.1 comes before alpha.beta, because numeric identifiers always sort before alphanumeric ones. A naive string comparison gets both of these wrong, which is why a dedicated checker matters even for something that looks as simple as ordering version strings.
The specification itself is a model of careful technical writing. Semantic Versioning 2.0.0 was authored by Tom Preston-Werner, the co-founder of GitHub, and it has been adopted by the package managers of nearly every major language, from npm to Cargo to Composer, because it solves a coordination problem that no single project could solve alone. Its success also illustrates a limit: SemVer is a social contract, not a law of nature, and it only works when publishers are honest about breaking changes. Tools like this checker can verify the form of a version, but they cannot verify the honesty of the change behind it, which is why changelogs, tests, and the judgement of maintainers remain irreplaceable.
A final practical note: when you publish a release, write the changelog entry in the same commit as the version bump, and make the bump itself a deliberate decision recorded in the release notes. Future maintainers will thank you, because the version number alone cannot explain why it changed. The same discipline applies to dependencies: pin the versions you ship with, review major bumps by hand, and let minor and patch updates flow automatically, since that division of labour is exactly what the contract was designed to enable. Treat every major release as a deliberate promise to your users, and document the breaking changes prominently so nobody upgrades by surprise.