Slopsquatting Check vs. Eyeballing package.json by Hand
Reading your own package.json works, and for a file you typed yourself, one dependency at a time, it can be the fastest check there is. It gets harder the moment the install command came from an AI assistant and you copied it rather than typed it -- you are now scanning a list of names for a one- or two-character difference from something you already trust, which is exactly the kind of change a fast read skips over. This free tool checks every name at once against a known-package list, entirely offline in your browser.
What each approach is for
Reading it by eye means opening package.json, or the diff that added a line
to it, and recognizing whether each dependency name looks right. For a short file, or a name you typed
yourself and already know, this can be the whole job -- no tool needed.
This checker parses the dependencies and devDependencies you
paste and compares every name's edit distance against roughly 130 extremely well-known packages, entirely
in your browser, with no network call of any kind. It flags a name that looks like a one- or two-character
typo of something famous -- the exact shape a slopsquatted or typosquatted name takes -- in a fraction of a
second, whether the file has three dependencies or thirty.
| Situation | Better fit |
|---|---|
| A handful of dependencies you typed yourself and already know by name. | Reading by eye -- often faster than pasting the file in here. |
| An AI assistant's install suggestion you copied without typing it yourself. | This checker -- it compares the exact spelling instantly instead of relying on a read that trusts the name because it "looks right." |
A longer package.json, or a name that is not close to anything on this tool's known-package list. | Both have limits here: a manual reader can miss a subtle near-miss among many lines, and this offline page has no way to know whether an unlisted name exists at all. |
| Whether a name that isn't a near-miss actually exists on the registry, and how old it is. | The companion CLI -- it makes the one live, read-only check this offline page deliberately does not. |
Treat this checker as a fast first pass across every name in the file, and a manual read as the judgment call on what a flagged (or not-flagged-but-unfamiliar) name is actually for. This page names no company or product being compared against -- reading a file by eye is a habit, not a competitor.
Common questions
Isn't reading my own package.json always going to be more reliable?
For a file you wrote by hand, one dependency at a time, it can be. It gets harder the moment an AI assistant wrote the install command for you and you copied it without typing the name yourself -- you are now reading a name you did not choose, looking for a one- or two-character difference from a package you already trust, which is precisely the kind of change a fast read skips over. This tool compares every name in the file against roughly 130 well-known packages in a fraction of a second, the same check every time, no matter how tired the read is.
What can a manual read catch that this tool cannot?
Context this tool has no access to: whether a name looks right for what the project actually needs, whether a teammate mentioned adding it, or whether it showed up in a diff nobody expected. The offline check only compares spelling against a short known-package list -- it has no opinion on whether a name that isn't a near-miss of something famous is safe, and it cannot tell you whether the name was ever intentional.
Does this replace checking the package for real?
No. A flag from this page is a prompt to read that one dependency before trusting it -- the same read you would otherwise be doing for every dependency, just narrowed to the names worth a second look. And the offline page cannot tell you whether an unflagged name actually exists on the registry at all; that is what the companion CLI checks, with one read-only request per name against registry.npmjs.org.
Why would a hallucinated name pass a careful manual read?
Because it is designed to. A model hallucinates names that sound exactly like something that should exist -- a plausible scoped package, a common utility-library shape -- and an attacker who has already registered that name is counting on a reviewer recognizing the shape and moving on. A near-miss of a package you already trust, buried among two dozen genuine dependencies, is the case a quick visual pass is built to miss and an edit-distance comparison is built to catch.