# npmx.dev is a front end for the npm registry, and it says so first

> npmx-dev/npmx.dev positions itself as an elevated developer experience over the existing registry rather than a replacement for it, and the documentation backs that up: administrative actions run through your own npm command line client, the two hostnames are documented as substitutions for the canonical one, and the feature comparison admits exactly one row where the other site wins.

**npmx-dev/npmx.dev** — a fast, modern browser for the npm registry

- Repository: https://github.com/npmx-dev/npmx.dev
- Website: https://npmx.dev
- Stars: 3,635 · Forks: 533
- Language: TypeScript
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/npmx-dev-npmx-dev

## It is a front end for the registry, not a replacement

The vision paragraph makes the positioning explicit and it is worth reading before anything else, because it determines what the project is. The stated goal is to build a fast, modern browser for the npm registry, and then the sentence that clarifies the scope: this is not replacing the registry, but providing an elevated developer experience through a fast, modern user interface. The mechanism that keeps that promise is in the admin feature, which says packages, teams and organizations are managed from the browser powered by your local npm command line client. So the site is a reader and a console, and the writes travel through credentials you already hold rather than through an account created here. That is also why the repository manifest is marked private at version zero point zero: nothing about this project is a publishable package.

## Two hostnames are documented as drop-in substitutions

One of the seven stated capabilities is that you can replace the canonical registry host in any address with one of two alternatives and it just works, and both alternatives are named. That is the whole product strategy in a sentence: no migration, no account, no import, just a different host in the bar. It is the reason the project can add features the canonical site does not have without asking anyone to move. Alongside that is a shortcut scheme on subdomains of the same domain, seven of them, and each points somewhere different rather than to a page on the site: a chat server, a builders' server, a social profile, the repository, the issue tracker, the code of conduct and the contributing guide. It is a small map of the project's own community in the address bar. The feature list adds a related commitment: every view on every page is shareable through the address, so a search result, a compare set, a diff, a documentation page or a single line of source can be sent to a colleague as a link rather than as a description. That is the feature the URL-compatibility claim depends on, and it is the reason the code viewer carries a permalink to specific lines rather than only to a file.

## The comparison table admits exactly one gap

The table against the canonical site is the most honest page in the documentation. It is a column per site with a tick or a cross, and the crosses cluster on one side: package comparison, URL-driven views, generated API docs, version diff, changelog view, timeline view, internationalization, an accessibility statement with audits, outdated dependency warnings, module format badges, install size calculation, install script warnings, license change warnings, replacement suggestions and a cross-reference to another package registry are all marked as available here and not there. Reading down the first column, though, exactly one row is the other way: the dependents list is marked as a work in progress on this side. And one row is annotated as newly available on the other side. So the honest summary is that this site is ahead on roughly fifteen rows and behind on one. The comparison is also the reason to read the rest of the feature list carefully: it is written in the register of a product page rather than a changelog, so the tick marks tell you what exists and the prose tells you how much to trust it.

## Ten forge hosts are polled for stars and forks

The repository support list is longer than any similar feature tends to be, and it names ten hosts in a single bullet: the two largest commercial forges, one more commercial, and then a run of independent and self-hosted ones including a federated host, a forge with two separate implementations listed separately, a gossip-based system, and a host that is not a forge at all. That breadth is the interesting engineering claim here, because each host has its own API shape and its own rate limits, and a package page has to merge the results into one number. Everything else on the page can be read from registry metadata, but stars and forks have to be fetched, and the ones from independent hosts are frequently absent rather than zero. A second cross-registry check asks whether a scoped package is also published on a different package registry, which is the same idea applied to availability rather than to popularity, and a further row reports module format, TypeScript type availability with a link to the separate types packages, and declared engine constraints. Between them those three features turn a package page from a readme into an inspection.

## Install size counts transitives and version ranges resolve

Two features on the package page come from doing dependency resolution in the browser rather than from the registry's own metadata. The first is total install size, stated explicitly as including transitive dependencies, which is a number nobody publishes and everybody wants. The second is version range resolution, with a caret range given as the example, resolving to the actual installed versions. That second one is the feature that makes the page useful for auditing rather than browsing, because it lets you see that a dependency you read as accepting a wide range has in fact been resolved to something specific, and therefore whether your own lockfile is honest. Both features are also the ones most exposed to change as the registry's dependency metadata changes, since neither number is stored in the registry and both are computed on the page. The comparison table also lists security advisories from a public vulnerability database, outdated dependency indicators, and warnings about licences changing, install scripts and module replacements, which is the same instinct applied to metadata rather than to code.

## Three public directories and four styling presets

The repository layout reveals how many environments this runs in. There are three separate public asset directories, one for production and two named for development and staging, which is what a site deployed to a platform with preview environments looks like from the inside. The styling layer is built from a utility framework configured through four separate preset files rather than one, two of which are named for the two hard requirements in the feature list: one for accessibility and one for right-to-left languages. Visual changes are checked with a component explorer and a screenshot-diff service configured at the root, and editor configuration is committed for two editors. The translation layer has its own tracking configuration and a generated lexicons directory, which is how a project keeps dozens of locales from drifting.

## Accessibility is a suite rather than a claim

Accessibility appears three times in the documentation and in each case it is measurable rather than aspirational. The feature list claims keyboard-friendly, screen-reader-aware support baked in from the start, and then specifies what that means operationally: automated checks from a browser accessibility engine and from a Lighthouse run. The scripts confirm it, with a dedicated accessibility test that builds a test bundle and runs the audit twice, once in dark colour mode and once in light, which is the detail that distinguishes a real audit from a checkbox. Keyboard navigation is documented concretely too: one key focuses the search field, another opens the code viewer, and the arrow keys move through results. Search also auto-loads further result pages as you scroll, so a query that returns thousands of packages does not need pagination clicks. The example configuration file names two secrets and nothing else, a session password and a signing secret for image proxy and social image URLs, and both carry a note that a random hex generator produces them. That is a small file, and for a site holding administrative credentials it is a reassuring one.

## Conclusion

npmx.dev suits someone who reads package metadata more often than they publish, and who wants the reading to be fast, linkable and checked by an automated audit before they trust it. It does not replace the registry and it is not a publishing tool you can migrate to, since the writes happen through your local client. Before relying on it, check the one feature the comparison marks as unfinished, decide whether you want your package metadata read from a third-party site rather than the canonical one, and set both of the two environment secrets the example configuration names.

## FAQ

### what is npmx dev

It is a browser for the npm registry rather than a replacement for it, and the documentation says so in the vision section. Administrative actions, covering packages, teams and organizations, are performed from the browser using your local npm command line client rather than through an account on the site.

### Is npm free to use?

The repository does not discuss the service's pricing. What it states about itself is that it is MIT licensed and open source, and that it provides an elevated developer experience over the existing registry through a fast, modern user interface.

### How to run npm in dev mode?

The repository does not document a development mode for the package manager. It documents its own scripts instead: a development server, a documentation development task scoped to a separate workspace package, and three separate test suites covering accessibility, performance and browser behaviour.

### Is npm owned by Microsoft?

Nothing in this repository addresses ownership of the registry. It links to the canonical site as the service it provides an interface for, and documents that substituting one of two alternative hostnames for the canonical one in any address works.

### What is npm run dev?

That command belongs to the package manager's own script runner, which this repository does not cover. Its own equivalent is a script that starts the development server for the application, alongside separate scripts for the documentation site and for a connector package that also has a mock mode.

## Sources

- [License: MIT](https://github.com/npmx-dev/npmx.dev/blob/main/LICENSE)
- [npmx-dev/npmx.dev on GitHub](https://github.com/npmx-dev/npmx.dev)
- [Project website](https://npmx.dev)
- [README](https://github.com/npmx-dev/npmx.dev/blob/main/README.md)
- [Releases](https://github.com/npmx-dev/npmx.dev/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/npmx-dev-npmx-dev