Checking Package Name Availability: npm, PyPI, Crates, and Beyond

If you are building a developer tool, a CLI, a library, or any open-source project, your package name is not an afterthought. It is the name developers will type into their terminals hundreds of times. It is what shows up in dependency files, in documentation, in Stack Overflow answers. A bad package name is a tax your users pay every time they interact with your project.

And unlike domains, where you can buy alternatives or use creative TLDs, package registries are often one-name-per-registry. If someone took config on npm, that is it. You cannot buy it from them. You cannot use a different extension. You need a different name or a different strategy.

Here is how to navigate package naming across every major registry.

Why Package Names Matter More Than You Think

Consider how developers interact with your package name:

• They type it in install commands: npm install your-package
• They import it in code: import { thing } from 'your-package'
• They reference it in documentation and tutorials
• They search for it when troubleshooting
• They recommend it to colleagues by name

A good package name is short, memorable, easy to type, and hard to misspell. A great package name also hints at what the package does.

express tells you it is fast. lodash is a play on underscore. fastify tells you exactly what it optimizes for. These names work because they are concise, distinctive, and relevant.

Now compare that to @organization/very-long-http-server-framework-v2. Functional, but nobody wants to type that.

The Major Registries

npm (JavaScript / TypeScript)

npm is the largest package registry in the world with over 2 million packages. Competition for names is fierce.

Naming rules:

• Lowercase only
• Can contain hyphens and dots (but not as first/last character)
• Maximum 214 characters
• Cannot start with a dot or underscore
• No URL-unsafe characters
• Cannot match Node.js core modules

How to check availability:

npm view <package-name>

If you get a 404, it is available. You can also check at https://www.npmjs.com/package/<name>.

The scoped package escape hatch: npm supports scoped packages in the format @scope/package-name. If utils is taken, you can publish @yourorg/utils. Scoped packages can be public and free.

This is increasingly the norm. Major projects like Angular (@angular/core), Babel (@babel/core), and Vue (@vue/cli) all use scopes. It signals organizational ownership and avoids naming conflicts.

PyPI (Python)

PyPI hosts over 500,000 packages and has some unique quirks.

Naming rules:

• Must start and end with a letter or number
• Can contain letters, numbers, hyphens, underscores, and dots
• Comparisons are case-insensitive and treat hyphens, underscores, and dots as equivalent
• my-package, my_package, and my.package are all the same name

That normalization rule is critical. If my-package exists, you cannot publish my_package. They are considered identical.

How to check availability:

pip index versions <package-name>

Or visit https://pypi.org/project/<name>/.

Common strategy: Python developers often use shorter, more creative names. Think flask, celery, pandas, rich. The Python community tends to favor single-word names that are evocative rather than descriptive.

crates.io (Rust)

The Rust package registry has around 150,000 crates and a notably strict naming policy.

Naming rules:

• Must start with a letter
• Only letters, numbers, hyphens, and underscores
• Hyphens and underscores are equivalent (my-crate and my_crate are the same)
• Maximum 64 characters

How to check availability: Visit https://crates.io/crates/<name> or use cargo search <name>.

Notable policy: crates.io has an active name squatting policy. If a crate name is registered but has no published content or appears to be squatted, you can file an issue to request the name. The Rust team reviews these on a case-by-case basis.

Go Modules

Go takes a fundamentally different approach. Package names are tied to their repository paths.

Naming convention:

github.com/username/package-name

There is no central registry to squat. Your package name is your repository URL. This means naming conflicts are structurally impossible, but it also means your name is inherently longer and tied to your hosting platform.

Strategy: Choose a concise, descriptive repository name. The Go community often references packages by their short name in conversation (e.g., “gin” for github.com/gin-gonic/gin), so pick something that works as a standalone word too.

Maven Central (Java / Kotlin)

Maven uses a group ID and artifact ID system based on reverse domain notation.

Naming convention:

com.example:artifact-name

Rules:

• Group ID should follow reverse domain name convention
• You must prove domain ownership to publish
• Artifact IDs follow the same rules as Java identifiers

Strategy: Because you need a domain to publish, the name squatting problem is smaller. But artifact names within your group still matter. Keep them concise: com.stripe:stripe-java is better than com.stripe:stripe-payment-processing-java-sdk.

NuGet (.NET)

NuGet hosts .NET packages with relatively straightforward naming.

Naming rules:

• No length limit (practical limit around 100 characters)
• Cannot differ only by case
• Dots are commonly used for namespacing: Microsoft.Extensions.Logging

How to check: Visit https://www.nuget.org/packages/<name> or use dotnet search <name>.

Convention: The .NET ecosystem heavily uses dot-separated namespacing. Company.Product.Feature is standard. This reduces naming conflicts but makes names longer.

Homebrew (macOS)

If your tool has a CLI component, Homebrew matters.

Naming rules:

• Formula names are lowercase with hyphens
• Must not conflict with existing formulae in homebrew-core
• Cask names (for GUI apps) follow similar rules

How to check:

brew search <name>

Strategy: Homebrew names should match your project name. If your project is called mytool, the formula should be mytool. If there is a conflict, Homebrew maintainers may ask you to use a more specific name.

Naming Rules Comparison

Registry	Case	Separators	Max Length	Normalization	Scoping
npm	Lowercase only	Hyphens, dots	214	None	@scope/name
PyPI	Case-insensitive	Hyphens, underscores, dots	None specified	All separators equivalent	None
crates.io	Case-sensitive	Hyphens, underscores	64	Hyphens = underscores	None
Go	Case-sensitive	Hyphens, underscores	None	None	Module path
Maven	Case-sensitive	Dots (group), hyphens (artifact)	None	None	Group ID
NuGet	Case-insensitive	Dots	None practical	Case-insensitive	Dot namespace
Homebrew	Lowercase	Hyphens	None	Lowercase	Tap prefix

Strategies When Your Name Is Taken

You found the perfect name. You checked the registry. It is taken. Now what?

1. Use Scoped Packages (npm)

This is the cleanest solution on npm. Create an organization scope and publish under it.

npm init --scope=@yourorg

The package becomes @yourorg/package-name. Users install with npm install @yourorg/package-name. It is slightly longer but unambiguous and professional.

2. Add a Meaningful Prefix or Suffix

If scoping is not available, add context:

• fast-csv instead of csv
• node-fetch instead of fetch
• py-spy instead of spy
• go-redis instead of redis

The prefix should add meaning, not just differentiate. x-csv tells you nothing. fast-csv tells you it is optimized for speed.

3. Use a Related Word

Thesaurus your way to a better name. If config is taken, consider rc, conf, dotenv, or settings. If http is taken, consider got, axios, ky, or undici.

Some of the most popular packages exist because the obvious name was taken and the alternative turned out to be more memorable.

4. Invent a Word

webpack, rollup, vite, bun, deno. None of these are dictionary words (well, some are, but not in the software context). Invented or repurposed words are distinctive, searchable, and almost always available across registries.

5. Claim Across Registries Simultaneously

If you are building a cross-language tool or plan to expand, check all relevant registries before settling on a name. Qezir checks package registries alongside domains and social handles, which saves you from discovering conflicts after you have already published on one registry.

Name Squatting Policies

Name squatting — registering a package name with no intention of publishing meaningful code — is a real problem. Each registry handles it differently.

npm

npm has a dispute resolution process. You can file a claim if:

• The package has no meaningful code
• The name infringes your trademark
• The name is being held to extract payment

npm’s policy has evolved over the years. They no longer allow “first come, first served” to override legitimate use cases. File disputes through the npm support page.

PyPI

PyPI has a PEP 541 process for name reclamation. Valid reasons include:

• The project is abandoned (no releases for an extended period)
• The name infringes a trademark
• The name contains a typo of a popular package (typosquatting)

The process involves filing an issue on the PyPI support repository.

crates.io

crates.io is proactive about squatting. Their policy states that names should be used in good faith. If a crate has no published versions or appears to be squatted, you can open an issue on the crates.io GitHub repository. The Rust team will review and potentially transfer the name.

Maven Central

Squatting is rare on Maven because you need to prove domain ownership. The reverse domain convention naturally prevents most conflicts.

NuGet

NuGet reserves certain prefixes for verified organizations. If someone is squatting a name that conflicts with your verified prefix, NuGet support can help resolve it.

Security Considerations

Package naming is not just about branding. It is also a security concern.

Typosquatting is a real attack vector. Malicious actors publish packages with names similar to popular ones (e.g., crossenv instead of cross-env), hoping developers mistype the name during installation. These malicious packages can steal credentials, inject backdoors, or exfiltrate data.

Dependency confusion is another risk, where attackers publish public packages with names matching internal private packages. When a build system resolves dependencies, it might pull the malicious public package instead of the intended private one.

Implications for your naming:

• Choose names that are hard to typo
• Avoid names too similar to popular packages
• If you use scoped packages internally, consider also claiming the unscoped name to prevent confusion
• Register your name across multiple registries even if you only publish on one, to prevent impersonation

A Practical Checklist

Before you commit to a package name:

1. Search all relevant registries. Not just the one you plan to publish on today.
2. Check the domain. packagename.dev or packagename.io is ideal for developer tools.
3. Check social handles. You will want consistent branding for documentation and community.
4. Test the typing experience. Open a terminal and type the install command ten times. Is it comfortable? Do you keep mistyping it?
5. Say it out loud. You will discuss this project in meetings, at conferences, and on podcasts. “We use [name]” should feel natural.
6. Check for unfortunate meanings. Search the name in multiple languages if you expect international adoption.
7. Verify the name is not similar to known malicious packages. A quick search through security advisories can save headaches.

The Package Name Is Part of the Product

Developers are your users. The install command is your onboarding flow. The import statement is your API surface. Your package name shows up in every package.json, requirements.txt, Cargo.toml, and go.mod that includes your work.

Treat it with the same care you would give your product name, because for developer tools, it is your product name. The time you spend finding the right name across registries pays dividends in adoption, discoverability, and trust.

Check early, check everywhere, and do not settle for a name that makes developers hesitate before typing it.