Choose a name that is unique, descriptive and all lowercase, does not copy a trademark, and for an unscoped package is not spelled like an existing one. A scope avoids many collisions. Then check the name by hand, because typosquatters work from near misses.
What npm's guidelines say
The npm package name guidelines list four rules for all packages:
- Be distinct. The name should be unique among existing packages.
- Be descriptive. It should show what the package does.
- Follow npm policy. Avoid offensive names, and do not use someone else's trademarked name.
- Use lowercase only.
Unscoped packages get two more:
- Do not use a name spelled similarly to another package.
- Do not use a name that leads people to misidentify the author.
The page does not say what triggers a rejection beyond pointing to the linked policies, so treat the guidelines as the minimum, not a guarantee.
A five minute name check
- Search the registry for the exact name and for close variants: swapped letters, a hyphen added or removed, a plural.
- Look at the most downloaded packages in your topic. Is your name one character away from any?
- Read the trademark policy the guidelines link to if your name includes a brand.
- Say the name aloud. If it sounds like a known tool, a user may type the wrong one.
- Decide on scope. A scoped name under your username or organization is clearly yours.
Why near misses matter
Attackers register names close to popular ones and wait for typos or for tools that hallucinate package names. Your new package could be on either side of that: a victim of a look-alike published later, or an accidental look-alike of something else. See how typosquatting campaigns pick targets and PyPI name normalization and lookalikes for the Python side.
Scoped or unscoped
| Scoped | Unscoped | |
|---|---|---|
| Name collision risk | Lower inside your scope | Higher |
| Default visibility | Private, needs the public access option | Public |
| Extra naming rules from npm | Fewer | Near-duplicate and authorship rules |
| Looks familiar to users | Slightly longer | Short |
The first publish quirk is covered in why scoped packages need the public access option.
After you pick
- Document the exact install command in the README, with the exact name, so users copy it rather than type it.
- Think about whether to reserve a similar name for the same project in another ecosystem. Ownership on one registry does not give you the name on another, and PyPI normalizes names differently.
- Set up account protections first, using the 2FA guide for solo publishers.
Quick check
Can I use uppercase letters in the name?
The npm guidelines say to use lowercase only.
Does picking a scope remove typosquat risk?
No. It protects names inside your scope, but look-alikes outside it can still confuse users.
Sources
Last reviewed: 19 October 2026.
