Package Latest Version Checker

Look up the current published version of a package across nine registries — npm, PyPI, Maven Central, NuGet, Go, crates.io, RubyGems, Packagist, and vcpkg — straight from the live source. Enter a version you already have to see instantly whether it is out of date.

Last updated: 2026-08-30

Scoped packages like @scope/name work too.

Leave blank to just see the latest version.

Key Features

  • Nine registries: npm, PyPI, Maven Central, NuGet, Go, crates.io, RubyGems, Packagist, and vcpkg from a single search box.
  • Every major language: JavaScript, Python, Java, Kotlin, Scala and other JVM languages, C#, Go, Rust, Ruby, PHP, and C/C++.
  • Live data: every lookup queries the registry at that moment — never a cached or bundled list.
  • Outdated check: enter the version you have and get a direct up-to-date or outdated verdict.
  • Deprecation warnings: deprecated npm packages and yanked gems are flagged clearly.
  • Release context: shows publish date, licence, homepage, and recent version history.
  • No account: no signup, no API key, no rate-limited middleman.

How to Use This Version Checker

  1. Pick the registry your package lives on. Maven Central covers every JVM language (Java, Kotlin, Scala, Groovy, Clojure); NuGet covers .NET and C#; vcpkg covers C and C++.
  2. Type the exact package name. The format varies: Maven wants groupId:artifactId, Packagist wants vendor/package, Go wants the full module path, and scoped npm packages need the @scope/ prefix.
  3. Optionally enter the version you currently have to compare against the latest.
  4. Press Check latest version or hit Enter.
  5. Read the result: the latest version, when it was published, and whether your version is behind.

Why Check Package Versions Against the Live Registry?

Dependency versions go stale quietly. A version number that was current when a tutorial was written, when a Stack Overflow answer was posted, or when an AI coding assistant was trained can be months or years behind by the time you copy it into a manifest. The failure is rarely loud: the install either pulls something far older than you intended, or fails outright because the version you named never existed.

This matters more than it used to. Code suggestions increasingly come from language models, and every model has a training cutoff — which means any version number it produces from memory is stale by construction. It has no way to know what shipped last week. Checking against the registry takes seconds and removes an entire category of install-time surprises, including the security exposure of unknowingly pinning to a release that has since been patched.

The same lookup is also the fastest way to audit an existing project. Paste in the version from your package.json, requirements.txt, Cargo.toml, Gemfile, or composer.json and you get an immediate verdict on how far behind you are, plus the publish date so you can judge whether the gap is a patch bump or years of drift.

Frequently Asked Questions

Does this tool send my data to your server?

No. Unlike most tools on this site, this one does need the internet — your browser queries the public package registry directly. The package name you type goes to that registry (npm, PyPI, Maven Central, NuGet, the Go module proxy, crates.io, RubyGems, Packagist, or vcpkg) and nowhere else. It never passes through our servers, and nothing is stored or logged.

Which registries are supported?

npm (JavaScript/TypeScript), PyPI (Python), Maven Central (Java, Kotlin, Scala, Groovy, Clojure and any other JVM language), NuGet (.NET/C#), the Go module proxy, crates.io (Rust), RubyGems (Ruby), Packagist (PHP/Composer), and vcpkg (C/C++). Each is queried through its official public API. ConanCenter, an alternative C/C++ registry, is available on our MCP server but not here, because it does not permit cross-origin browser requests.

Why does it say my package was not found?

Most often a spelling or scoping issue. Scoped npm packages need the full @scope/name, and Packagist requires vendor/package. It can also mean the name genuinely does not exist — worth knowing, since a plausible-looking package name may simply have been invented.

Does “latest” include pre-releases and beta versions?

No. The result shows the latest stable release — the npm latest dist-tag, the crates.io maximum stable version, and the equivalent elsewhere. Betas, canaries, and release candidates are excluded so the version shown is the one safe to install. Maven Central needs particular care here: its own release marker happily points at an alpha or release candidate, so those are filtered out and reported separately rather than presented as the current version.

How does the outdated comparison work?

It compares numeric version segments in order, so 1.9.0 is correctly recognised as older than 1.10.0. Versions with non-numeric schemes cannot be compared automatically, and the tool says so rather than guessing.

Can I use this offline?

No — this is the one tool on the site that cannot work offline, because the whole point is fetching information that only exists on a live server. Every other tool here runs entirely in your browser.

Is there a rate limit?

We impose none. Requests go straight from your browser to the public registry, so only that registry's own limits apply — generous enough that normal interactive use will not reach them.

Can AI agents use this too?

Yes. The same lookup is exposed as dev_package_latest_version on our MCP server, so Claude, Cursor, and other MCP-capable agents can check a version themselves before recommending it.