QuickWebTools.
Get things done

Developer · FREE ONLINE TOOL

SemVer Calculator

Calculate the next semantic version after a patch, minor, or major bump. Compare two versions. Check if a version satisfies a range like ^1.4.0. Free, no signup.

Loading tool...

How to use SemVer Calculator

  1. Enter your current version in the Version Bump section to see patch, minor, and major options
  2. Click the copy button next to the version you need
  3. Use the Version Comparator to check which of two versions is newer
  4. Use the Range Checker to test if a version satisfies a semver range like ^1.4.0 or ~2.1.0
  5. Refer to the SemVer Quick Reference at the bottom for range syntax reminders

Examples & practical tips

  • 1.4.2 + bug fix → 1.4.3 (patch bump)
  • 1.4.2 + new feature → 1.5.0 (minor bump)
  • 1.4.2 + breaking change → 2.0.0 (major bump)
  • 1.5.1 satisfies ^1.4.0 → yes (same major, >= minor)
  • 2.0.0 satisfies ^1.4.0 → no (different major)

About SemVer Calculator

Semantic Versioning (SemVer) is the versioning standard used by npm, Cargo, RubyGems, and most modern package ecosystems. Our SemVer Calculator helps you answer the questions that come up every time you cut a release.

What this tool does:

Version Bump Calculator — Enter your current version (e.g. 1.4.2) and instantly see the correct next version for a patch fix, new feature, or breaking change. No more guessing whether a new API method should be a minor or patch bump.

Version Comparator — Is 2.0.0-alpha.1 greater or less than 1.9.9? Is 1.10.0 greater than 1.9.0? Semver has specific comparison rules that aren't obvious — this answers them instantly.

Range Checker — Does version 1.5.1 satisfy the range ^1.4.0? Does 2.0.0 break a ~1.2.3 range? Essential for understanding npm dependency resolution and figuring out which package versions are compatible.

SemVer Rules (MAJOR.MINOR.PATCH): - MAJOR — increment when you make incompatible API changes - MINOR — increment when you add functionality in a backwards-compatible manner - PATCH — increment when you make backwards-compatible bug fixes

Pre-release versions: Add a hyphen and label after the patch version: 1.0.0-alpha, 1.0.0-beta.1, 1.0.0-rc.2. Pre-release versions have lower precedence than the associated normal version.

Range syntax: - `^1.2.3` — compatible with version (>=1.2.3 <2.0.0) - `~1.2.3` — approximately equivalent (>=1.2.3 <1.3.0) - `>=1.0.0` — greater than or equal to

Used by npm, Yarn, pnpm for dependency resolution. Understanding ranges is essential for managing package.json dependencies safely.

When this comes in handy

  • Deciding the correct next version before cutting a release
  • Understanding npm dependency range resolution
  • Checking if a package update will break your semver range
  • Learning semantic versioning rules interactively
  • Verifying pre-release version ordering

Frequently asked questions

What is semantic versioning?

Semantic Versioning (SemVer) is a versioning scheme for software that conveys meaning about the underlying changes. Version numbers follow the MAJOR.MINOR.PATCH format: MAJOR for breaking changes, MINOR for new backwards-compatible features, PATCH for backwards-compatible bug fixes.

What does the ^ (caret) mean in package.json?

The caret ^ allows changes that do not modify the left-most non-zero digit. For ^1.2.3 it allows >=1.2.3 <2.0.0. For ^0.2.3 it allows >=0.2.3 <0.3.0. This is npm's default range operator and allows minor and patch updates while protecting from major breaking changes.

What does ~ (tilde) mean?

The tilde ~ allows patch-level changes if a minor version is specified. ~1.2.3 allows >=1.2.3 <1.3.0. It is more conservative than caret — only allowing patch updates, not minor version bumps.

When should I bump the major version to 1.0.0?

When your software is ready for public use and you want to commit to a stable API. Before 1.0.0, the 0.x.x range is considered unstable — anything may change at any time. Once you reach 1.0.0, semantic versioning rules fully apply and breaking changes must increment the major version.

How do pre-release versions compare?

Pre-release versions (1.0.0-alpha, 1.0.0-beta.1) have lower precedence than the associated release. So 1.0.0-alpha < 1.0.0-beta < 1.0.0-rc.1 < 1.0.0. Within pre-releases, identifiers are compared numerically if numeric, and lexically otherwise.

Conventional Commits: Complete Team Setup Guide (commitlint + Husky + semantic-release)

Set up commitlint and Husky with a correctly quoted commit-msg hook, then configure release analysis and check the workflow in CI.

Read guide

GitFlow vs Trunk-Based Development: Which Should You Use?

Compare integration, release support and branch lifetimes to choose a workflow. Includes diagrams, practical scenarios and the limits of each approach.

Read guide

KEEP THINGS MOVING

All tools

Developer

Conventional Commits Reference

Format and validate git commit messages against the Conventional Commits v1.0.0 spec. Real-time linting, type selector, breaking change support.

Security

Hash Generator

Calculate real MD5, SHA-1, SHA-256, SHA-384, and SHA-512 hashes from text.

Developer

Diff Checker

Compare two text files and find the differences instantly.