Is 1.2.10 bigger than 1.2.9?

Yes. In semantic versioning each of major, minor and patch is compared as a number, not as text. A naive string sort reads the patch field character by character and decides 1.2.9 wins because the character 9 sorts after 1. This tool parses 10 and 9 as integers, so 1.2.10 is correctly the newer release. That single rule is the most common reason people reach for a real semver comparator.

Why is 1.0.0-alpha treated as older than 1.0.0?

A pre-release tag marks a version that is not yet the final release, so the spec gives it lower precedence than the version it leads up to. That means 1.0.0-alpha, 1.0.0-beta and 1.0.0-rc.1 all rank below 1.0.0. Inside the pre-release the dotted identifiers compare left to right: 1.0.0-alpha.1 is older than 1.0.0-alpha.2, and a numeric identifier such as 1 ranks below an alphanumeric one such as alpha.

What happens to build metadata like +build.42?

Build metadata is parsed and shown but ignored when comparing, exactly as semver.org requires. So 1.0.0+build.1 and 1.0.0+build.999 are equal, and 1.2.3+abc equals 1.2.3. Build metadata only records how an artifact was produced (a commit hash, a CI run number); it never makes one version newer than another. If you need ordering, put the difference in the pre-release tag instead.

What do the ^ and ~ range operators mean?

A caret like ^1.2.3 allows any newer version that keeps the same left-most non-zero number, so 1.9.0 satisfies it but 2.0.0 does not. When the major is 0 the caret pins the minor instead, so ^0.2.3 allows 0.2.9 but not 0.3.0. A tilde like ~1.2.3 is tighter: it allows patch bumps only, so 1.2.9 passes but 1.3.0 fails. The range box here checks version A against whichever operator you type.

How do I sort a whole list of versions at once?

Paste them into the list box, one per line or comma-separated, and the tool returns them ordered oldest to newest using the same precedence rules. A mix like 1.0.0, 1.0.0-alpha, 2.0.0, 1.0.0-rc.1, 1.2.0 sorts to 1.0.0-alpha, 1.0.0-rc.1, 1.0.0, 1.2.0, 2.0.0. Lines that are not valid versions are dropped quietly so one typo never breaks the whole sort.

Decide whether a dependency update is safe to take

Your lockfile pins react at 18.2.0 and a PR bumps it to 18.3.1. Drop both into version A and B and confirm the new one is genuinely newer, then paste the package.json range like ^18.2.0 into the range box to verify the bump still sits inside what you declared. No more eyeballing whether 18.10 is above or below 18.9.

Sort a pile of git tags into release order

A repo has tags v1.0.0, v1.0.0-rc.2, v1.2.10, v1.0.0-rc.10 and v1.2.9 scattered across branches. Paste them into the list box and get them back oldest to newest, with the release-candidate ordering and the 1.2.10-after-1.2.9 fix both handled, so your changelog lists them in the correct sequence.

Explain a version bug to a teammate with a shareable link

Someone insists their build shipped a newer version because the string looked bigger. Compare the two here, copy the URL, and the link opens with both versions filled in and the verdict on screen. The highlighted differing segment makes it obvious where the confusion came from.

Validate a CI gate that only ships newer versions

Before writing a release script, sanity-check the comparison logic by hand: does 2.0.0-beta.1 really rank below 2.0.0, does build metadata drop out, does ~2.1.0 reject 2.2.0. Confirm each rule here first so the automated gate behaves the way the spec says it should.

Semver Compare — Which Semantic Version Is Newer

Tell which semantic version is newer, sort a whole list, and check ^ ~ >= ranges, all in the browser

Runs locally
Category Developer & DevOps
Best for Formatting, validating, shrinking, or inspecting code-adjacent text.

Version A

Version B

Result

1.2.10 > 1.2.9

1.2.10 is newer, 1.2.9 is older.

First difference at: patch

Range checkDoes version A satisfy this range?

1.2.10 satisfies ^1.2.0

Sort a list of versionsOne version per line or comma-separated

Sorted (oldest → newest)

1.0.0-alpha
1.0.0-rc.1
1.0.0
1.2.0
2.0.0

What this tool does

A semantic version comparator built on the semver.org rules, not on the string sort that wrongly puts 1.2.9 above 1.2.10. Type two versions and it tells you a is less than, equal to, or greater than b, and highlights the first segment that differs. It parses major.minor.patch plus an optional pre-release tag (1.0.0-alpha.1) and build metadata (+build.42), and follows the spec faithfully: a pre-release ranks below the matching release, numeric identifiers compare as numbers, numeric identifiers rank below alphanumeric ones, and build metadata is ignored entirely when comparing. Paste a messy list and it sorts oldest to newest. Check whether a version satisfies a caret, tilde, or comparator range such as ^1.2.3, ~1.2.3, or >=1.2.0. Everything runs client-side and the two versions live in the URL so you can share a comparison with one link.

Tool details

Input: Files + Text + Numbers; The page exposes text boxes, numeric controls, file pickers, or structured inputs depending on the tool.
Output: Live result + Copy; The result area focuses on usable output, with copy, download, or preview actions when supported.
Privacy: Browser-side processing; The main tool logic does not call an external API, so inputs normally stay in the current tab.
Save / share: Shareable URL state; Key settings are encoded in the URL so another person can reopen the same setup.
Performance budget: Initial JS <= 9 KB; No WASM budget is declared, keeping the tool quick to open on mobile.
Best fit: Developer & DevOps · Developer; Category and role tags drive related tools, internal links, and quick fit checks.

How to use

1. Input

Paste or drop your content into the tool panel.
2. Process

Click the button. All processing is local in your browser.
3. Copy / Download

Copy the result or download to disk in one click.

How Semver Compare fits into your work

Use it in the small gaps between coding, reviewing, debugging, and shipping.

Developer jobs

Formatting, validating, shrinking, or inspecting code-adjacent text.
Preparing snippets for documentation, tickets, commits, or handoff.
Checking a small payload quickly without switching tools.

Developer checks

Run irreversible transforms like minify or obfuscate on a copy.
Keep secrets out of pasted snippets unless the tool explicitly stays local.
Use your normal tests or linter before shipping transformed code.

Good next steps

These links move the current task into a more complete workflow.

Real-world use cases

Decide whether a dependency update is safe to take
Your lockfile pins react at 18.2.0 and a PR bumps it to 18.3.1. Drop both into version A and B and confirm the new one is genuinely newer, then paste the package.json range like ^18.2.0 into the range box to verify the bump still sits inside what you declared. No more eyeballing whether 18.10 is above or below 18.9.
Sort a pile of git tags into release order
A repo has tags v1.0.0, v1.0.0-rc.2, v1.2.10, v1.0.0-rc.10 and v1.2.9 scattered across branches. Paste them into the list box and get them back oldest to newest, with the release-candidate ordering and the 1.2.10-after-1.2.9 fix both handled, so your changelog lists them in the correct sequence.
Explain a version bug to a teammate with a shareable link
Someone insists their build shipped a newer version because the string looked bigger. Compare the two here, copy the URL, and the link opens with both versions filled in and the verdict on screen. The highlighted differing segment makes it obvious where the confusion came from.
Validate a CI gate that only ships newer versions
Before writing a release script, sanity-check the comparison logic by hand: does 2.0.0-beta.1 really rank below 2.0.0, does build metadata drop out, does ~2.1.0 reject 2.2.0. Confirm each rule here first so the automated gate behaves the way the spec says it should.

Common pitfalls

Trusting a plain string or alphabetical sort. That puts 1.2.9 above 1.2.10 because it compares the patch field character by character. Each numeric segment must be compared as an integer, which is exactly what this tool does.
Assuming a pre-release is newer than its release. 1.0.0-rc.1 comes before 1.0.0, not after. A pre-release tag lowers precedence; only the bare 1.0.0 is the finished release.
Thinking build metadata changes ordering. 1.0.0+build.5 is not newer than 1.0.0+build.1. Build metadata is ignored when comparing, so move any meaningful difference into the pre-release tag instead.

Privacy

Parsing, comparing, sorting and range-checking all run as plain JavaScript in your browser tab. No version string is ever uploaded and nothing is logged. The one thing to know: the two compared versions are stored in the page URL so a share link reopens the same comparison, which means a link pasted into chat records those version strings in the recipient server access log. The list box and range box stay local and never enter the URL.

FAQ

Tool combos

Folks in your role tend to reach for these alongside this tool.

Developer

Browse all tools for this role

Semver Compare — Which Semantic Version Is Newer

What this tool does

Tool details

How to use

1. Input

2. Process

3. Copy / Download

How Semver Compare fits into your work

Developer jobs

Developer checks

Good next steps

Real-world use cases

Decide whether a dependency update is safe to take

Sort a pile of git tags into release order

Explain a version bug to a teammate with a shareable link

Validate a CI gate that only ships newer versions

Common pitfalls

Privacy

FAQ

JSON Formatter & Validator

Semantic Version Normalizer

Semantic Version List Validator

Semantic Version Extractor

Package Lock Dependency Auditor

AI Eval Planner

API Key Generator

ASCII Table Generator

ASCII Table Reference

awk + sed Cheatsheet

AWS CLI Cheatsheet

Backup Codes Generator