Current version

Major: 1Minor: 2Patch: 3

Bump type

Major→ 2.0.0

Breaking change — incompatible API change

Minor→ 1.3.0

New feature — backwards-compatible

Patch→ 1.2.4

Bug fix — backwards-compatible

Pre-major→ 2.0.0-alpha.0

Next major release candidate

Pre-minor→ 1.3.0-alpha.0

Next minor release candidate

Pre-patch→ 1.2.4-alpha.0

Next patch release candidate

Prerelease→ 1.2.4-alpha.0

Increment prerelease number

New version

1.2.4

Git tag: v1.2.4

npm range implications

^1.2.4 → matches >=1.2.4, <2.0.0

Allows compatible upgrades (default in npm install)

~1.2.4 → matches >=1.2.4, <1.3.0

Allows patch-level changes only

==1.2.4 → matches only 1.2.4

No upgrades allowed (most strict)

package.json snippets

"dependencies": { "my-package": "^1.2.4" }

"devDependencies": { "my-package": "~1.2.4" }

"version": "1.2.4"

What is Semver Checker and Version Calculator?

A semver checker validates whether a version follows the MAJOR.MINOR.PATCH shape, then helps you reason about the next release. Semantic versioning assigns version numbers that communicate the nature of changes: a major bump (1.0.0 to 2.0.0) signals breaking API changes, a minor bump (1.0.0 to 1.1.0) signals backwards-compatible new features, and a patch bump (1.0.0 to 1.0.1) signals backwards-compatible bug fixes. This tool validates the version you enter, calculates the correct next version for each bump type, and shows npm-compatible caret and tilde ranges so you can predict how consumers of your package will be affected.

How to Use

Enter your current version number to validate it (for example, 1.2.3 or v2.0.0-beta.1).
Select the bump type: major, minor, patch, or one of the pre-release variants.
For pre-release bumps, set the tag label (alpha, beta, rc, or a custom tag).
The new version and its npm-compatible caret and tilde ranges appear on the right.
Copy the version string for use in package.json, Git tags, or release scripts.

Why Use This Tool?

Instantly calculates the correct next version without mental arithmetic or manual error

Works as a semver validator for release tags, package versions, and CI checks

Shows caret (^) and tilde (~) range implications so you understand how consumers are affected

Handles pre-release version incrementing automatically (beta.1 to beta.2)

Displays all bump types at once for side-by-side comparison

Supports versions with existing pre-release tags (1.0.0-beta.2 becomes 1.0.0-beta.3)

Tips & Best Practices

Start new projects at 0.1.0 — version 0.x.y signals initial development with no stability guarantees
For breaking changes during 0.x development, bump the minor version (0.1.0 to 0.2.0), not major
npm caret (^1.2.3) allows minor and patch bumps; tilde (~1.2.3) allows only patch bumps
Git tag convention uses a "v" prefix (v1.2.3) even though the semver spec itself has no prefix
Use pre-release versions for feature flags and testing: 1.3.0-beta.1, 1.3.0-beta.2, then 1.3.0

Frequently Asked Questions

Can I use this as a semver checker or validator?

Yes. Enter a version such as 1.2.3, v2.0.0-beta.1, or 0.4.2 and the tool validates whether it matches the semantic version shape. If the input is invalid, the page shows an error instead of calculating a bump. It is useful for checking release tags before publishing a package or cutting a GitHub release.

What is the difference between ^ and ~ in package.json?

Caret (^) allows updates that do not change the leftmost non-zero digit: ^1.2.3 allows >=1.2.3 and <2.0.0. Tilde (~) allows patch-level changes only: ~1.2.3 allows >=1.2.3 and <1.3.0. For 0.x versions, caret is more restrictive: ^0.2.3 allows only >=0.2.3 and <0.3.0. Use caret when you trust the maintainer follows semver; use tilde for stricter control.

When should I use a pre-release version?

Use pre-releases (1.3.0-beta.1) when a feature is ready for testing but not for production. The naming convention: alpha for internal testing, beta for external testing, rc for release candidates that are feature-complete. npm will not install a pre-release version unless explicitly requested (npm install package@next or npm install [email protected]).

How do I handle breaking changes in a 0.x version?

By semver convention, major version 0 is for initial development where anything may change at any time. Many projects treat minor version bumps (0.1.0 to 0.2.0) as breaking changes during 0.x development. Once you publish 1.0.0, you commit to semver guarantees: no breaking changes without a major bump.

When should I NOT use this calculator?

This tool follows standard semver (MAJOR.MINOR.PATCH) and does not handle calendar versioning (CalVer), zero-based versioning, or custom version schemes used by some projects. It also does not validate whether a version has already been published to npm or PyPI — use npm view or pip index for that.

Is my version data kept private?

Yes. All version parsing and bump calculations run entirely as client-side JavaScript in your browser. No version numbers, package names, or project details are sent to any server, API, or third-party service.

What does the ~= operator mean in Python compared to semver?

In Python (PEP 440), ~=2.3 means >=2.3, <3.0 — similar to npm caret. In npm semver, ^2.3.0 means >=2.3.0, <3.0.0. The key difference is that Python version specifiers often omit the patch number while npm always requires MAJOR.MINOR.PATCH. This calculator focuses on npm/Node.js semver conventions.

Real-world Examples

Preparing a Minor Feature Release

Your package is at 2.4.1. You have added a new backwards-compatible feature. Select "Minor" to see that the next version is 2.5.0, and that consumers using ^2.4.1 will automatically receive the update.

Input

2.4.1 → Minor bump

Output

2.5.0 — ^2.5.0 allows >=2.5.0 <3.0.0, ~2.5.0 allows >=2.5.0 <2.6.0

Starting a Pre-Release Cycle for a Major Version

Your package is at 3.8.2 and you are preparing breaking changes for 4.0.0. Select "Pre-major" with tag "beta" to generate 4.0.0-beta.0, then increment through beta.1, beta.2 until ready for the stable 4.0.0 release.