Registering a handful of obvious lookalike names for your package can help, but it will never cover every typo, and it adds packages you must maintain. Prefer a scoped name, a clear README and monitoring for lookalikes, and register extra names only for the highest risk variations.
What the rules say
npm's package name guidelines say an unscoped package name should not be spelled in a similar way to another package name, and should not confuse others about authorship. Those similarity and authorship criteria are stated for unscoped packages. The page does not explain scoped naming in detail.
That helps a little. Registry rules reduce some lookalike publishes, but npm's guidance is a policy statement, not a promise that every confusing name is blocked. Attackers use many tricks, including swapped letters, dropped hyphens and extra words.
The case for defensive registration
- You block the most likely typos of a popular package.
- You can point the extra packages to the real one with a short README.
- The cost is low for a few names.
The case against
- The space of typos is huge. You cannot register them all.
- Each placeholder is another package to own, secure and keep 2FA protected.
- A placeholder that is abandoned can itself become a risk if account access is lost.
- It can look like name squatting, which registries discourage.
A practical middle path
| Action | Worth it? |
|---|---|
| Publish under a scope you control | Yes. A scope name is hard to imitate without being obviously different. |
| Register two or three of the most likely typos | Often yes, for popular packages |
| Register dozens of variants | Rarely |
| Add a clear README stating the exact install command | Yes |
| Watch for new packages with similar names | Yes |
| Tell users to copy the install line from the official site | Yes |
How to tell users the right name
Put the exact package name and the install command at the top of your README and docs site. Pin the name in your examples. Typosquats win when people type from memory. If you have AI generated install suggestions in your docs, check them too, since assistants sometimes invent names. See does npm provenance stop slopsquatting.
What a typosquat hunter looks for
Scanners flag names within a small edit distance of a popular package, packages with few downloads and a recent first publish, and new install scripts. For background, read anatomy of a typosquatting campaign and how to detect typosquatting in package installs.
If you find one
Report it to the registry using how to report a malicious package, and warn users with a short pinned issue.
Safeguard dependency scanning shows exactly which packages your project pulls in, so a lookalike stands out; the free scan is at gold.safeguard.sh/scan.
Quick check
Does npm stop all similar names?
No. The guidelines ask publishers to avoid similar names for unscoped packages, but they are guidance and cannot catch every case.
Is a scope enough?
It helps, since the scope is part of the name, but users can still mistype it. Make the install line easy to copy.
Sources
Last reviewed: 19 October 2026.
