Paste a package.json or a lockfile. See when each version was published, with flags for new releases, bursts, install scripts and deprecations.
To check how old your npm dependencies are, paste a package.json or a lockfile and this tool looks up the publish date of every package version in the public npm registry, then flags the versions that are new, that came in a burst, that run install scripts or that are deprecated. A version published a few hours ago has had little time to be looked at by anyone, which is why some teams wait before installing new releases. AGE marks a version published less than a number of days ago. The default is 14 days and the slider goes from 1 to 90. BURST marks a version when 3 or more versions of the same package were published inside one 24-hour window that also holds the version you use. INSTALL SCRIPTS marks a version whose manifest declares a preinstall, install or postinstall script, or that the registry marks as having an install script. Such a script may run when the version is installed, unless install scripts are disabled, for example with ignore-scripts. DEPRECATED marks a version its maintainer deprecated. NOT IN REGISTRY marks a package or version the registry does not have. Worked example: with a check made on 15 October 2026 at 12:00 UTC, a version published on 14 October at 10:00 UTC reads 1 day ago and gets AGE. If versions 2.0.1 at 09:00, 2.0.2 at 09:40 and 2.0.3 at 18:00 went out on the same day, each of the three also gets BURST.
It reads package.json, package-lock.json (lockfile versions 1, 2 and 3), npm-shrinkwrap.json, yarn.lock (version 1, and the Yarn 2 and newer format) and pnpm-lock.yaml (versions 5, 6 and 9). In a pnpm lock, packages you name yourself are marked direct, and a package only the dev dependencies reach counts as dev. A lockfile names the exact version of every package, so the table shows what you install. A package.json holds ranges such as ^4.19.2, so each range is resolved to the version npm would pick today: the latest tag if it fits the range, otherwise the highest version that fits, avoiding deprecated ones. That ignores what other packages need and any overrides, so a lockfile is the better input. peerDependencies are not read. Packages from git, a file path, a link, a workspace or a tarball address are skipped and counted, and their names are not sent. So are packages whose lockfile entry names another registry, which package-lock.json and yarn.lock version 1 do. A package.json, a Yarn 2 and newer lock and a pnpm lock do not record the registry, so a private package there looks like a public one: its name would be sent to the public registry. For scoped names (@scope/name) from those files the page asks you to tick a box first. Direct dependencies are looked up first, then the rest, up to 400 package names; the page says how many were left out. The Include dev dependencies switch leaves out devDependencies, or lockfile entries marked dev. A pasted or loaded file can be up to 4,000,000 characters.
Once the table shows what is new, the page gives a ready command, for example npm install --before=2026-10-01 for a check on 15 October 2026 with the default 14 days. The npm documentation says that with --before, only versions that were available on or before that time get installed, that npm errors if no version is available for the current set of direct dependencies, and that for a dist-tag that does not pass the filter, the most recent version before it is used. Current npm documentation also lists a min-release-age setting, a number of days, which does the same with a relative window. The date is midnight UTC at the start of the day, so it can be up to a day older than the exact cutoff. If your .npmrc has min-release-age-exclude entries, npm exempts the matching packages from --before as well, so they can still resolve their newest version. Read your .npmrc before relying on the command. The command is a starting point: run it in a branch and read the diff of the lockfile.
Pressing Check sends one request per package name to registry.npmjs.org, with the name in the address and nothing else: no cookies, no referrer, no versions. The abbreviated metadata the registry offers has no publish times, so the full document is read, and for a package with thousands of versions that can be several megabytes. Six requests run at a time, each stops after 30 seconds, and Cancel stops the rest. A package that could not be checked is shown as Not checked, and pressing Check again retries only those. A document larger than 16 MB is refused. A package with more than 20,000 versions keeps only the versions your file names and the dist-tag targets, and a range that cannot be resolved from those shows Too many versions instead of a guess. Answers are kept in memory for the visit, so changing the number of days or the sort never asks again. The tool reports the registry's recorded publish time. It does not scan code, and it does not know whether an install script is harmful or a new version is bad. A flag is a reason to look, not a verdict.
Paste your package-lock.json, yarn.lock, pnpm-lock.yaml or package.json, press Check, and read the Published column, which shows a date and how long ago it was, such as 2026-10-14 (1 day ago). A lockfile shows the versions you install today. Sort by Newest first to see the most recent ones at the top.
Three or more versions of the same package were published inside 24 hours, and the version you use is among them. For example, 2.0.1 at 09:00, 2.0.2 at 09:40 and 2.0.3 at 18:00 on one day all get BURST. It is not proof of anything: maintainers also fix a mistake with a quick patch release. It is a reason to look at the changelog.
A package.json holds ranges such as ^4.19.2, so the tool shows the version npm would pick today, which can be newer than the one your lockfile pinned months ago. Paste the lockfile to see what is actually installed. The tool cannot see overrides or what other packages require.
Run npm install --before=2026-10-01, with the date the page shows for your check, so that only versions published on or before that date are installed. npm also has a min-release-age setting in days. Packages matching min-release-age-exclude in your .npmrc are exempt from both. Either can fail if a dependency has no version old enough, and npm then reports an error.
The public registry has no package with that name, no such version, or no version that fits the range. The cause can be a private package, a typo, or a version that was unpublished. Packages from git, file, link or workspace entries, and from another registry named in the lockfile, are skipped before the check, so they are counted as skipped and not as missing.
No file is uploaded. It is read in your browser, in this tab. Pressing Check sends the package names, and only the names, to registry.npmjs.org, because the publish dates come from there. The versions and the rest of the file are not sent. Scoped names from a package.json, Yarn 2+ or pnpm file wait for your tick, because those files do not say if a package is private. Your settings (days, dev dependencies, sort and filter) are saved in this browser, the text is not.