npm Downloads Scraper - Package Trends & Growth

What does npm Downloads Scraper do?

Compare npm libraries on what actually decides a dependency choice: how many people use them, which way that is going, and whether anyone still maintains them.

The registry answers those three questions in three separate endpoints, and none of them gives a trend. Download history is published day by day, never as a direction.

No API key. No account.

---

The trend the registry hides — and nearly gets wrong

npm's daily download series contains gaps. Not quiet days: actual missing days, published as zero.

React's last thirty days:

2026-08-13  Thu   28,442,032
2026-08-14  Fri            0     <- missing
...
2026-09-03  Thu            0     <- missing
2026-09-07  Mon            0     <- missing
2026-09-08  Tue            0     <- missing
2026-09-09  Wed   32,073,030

React does not fall from 28 million to zero and back to 32 million. Four days were missing that month — three of them in the second half.

Take the series at face value and every library looks like it is dying:

Package	Naive trend	Corrected
react	−13.0%	+0.2%
solid-js	−6.1%	+9.5%
htmx.org	—	+7.1%
svelte	−22.0%	−2.1%
angular	−51.2%	−45.7%

Zero of ten packages growing, against seven of ten once the gaps are excluded. Angular stays down because that decline is real — the angular package is AngularJS, and it is genuinely being abandoned.

Every row carries missingDays so you can see how much of the period was actually published.

---

The four things this does that the source does not

1. A comparison table.

React 647M monthly downloads, Vue 58M, Svelte 20.6M, Solid 15M — four numbers side by side, from one run. The registry answers one package per request; downloads are fetched in batches of 30.

2. A trend that survives scrutiny.

Gaps excluded, the last two days dropped as unconsolidated, and blocks of seven days compared — because splitting thirty days in half gives fifteen against fifteen, which is two weeks and a day, and whichever block inherits the extra weekend looks like it is falling. Averages per valid day are compared, not sums.

3. The small document.

Fetching a package returns its entire version history: 6.8 MB for React, 2,951 versions. The /latest endpoint returns the same useful metadata in 2.1 KB.

4. Abandonment, dated.

daysSincePublish says what no quality score says. A library with millions of weekly downloads and no release in two years is a risk, and it scores well on every other measure.

---

Field coverage

Measured on ten front-end frameworks.

Field	Coverage
package, version, description, license	100%
downloadsLastWeek, downloadsLastMonth, downloadsLastYear	100%
trendPct, dailyAverage, missingDays	100%
repository, unpackedSizeKb	100%
daysSincePublish	80%
dependencyCount	60%

No npm score is published here, and that is measured

npm exposes four scoring fields. None of them is included, for two separate reasons.

score.final reads 2,459 for React because it is a search relevance score, not a quality rating. Publishing it as "npm score" would invite exactly the wrong reading.

score.detail.quality, .popularity and .maintenance are worse. Measured 17 September 2026 across eleven packages, from react down to is-odd — a one-line package — all three return exactly 1.0000 in every case:

Package	quality	popularity	maintenance
react	1.0000	1.0000	1.0000
express	1.0000	1.0000	1.0000
is-odd	1.0000	1.0000	1.0000
pad-left	1.0000	1.0000	1.0000

npm has frozen these scores. A quality column that grades React and is-odd identically promises an assessment that is not happening.

What does measure adoption is in the table above: the download figures, the slope between them (trendPct), and how recently the package was published.

---

What it is for

• Choosing a dependency. Downloads, trend, maintenance and last release for every candidate, in one table.
• Watching a competitor's open-source project. Adoption curve without asking them.
• Auditing a stack. Feed your package.json dependency list in and see which ones stopped being maintained.
• Ecosystem research. Search by keyword and rank by adoption to see what a category actually looks like.
• Developer marketing. Where your library sits against the alternatives, weekly.

Three dataset views ship with the Actor: Adoption, Health and Package profile.

---

Limits

Stated plainly, because they affect what you can conclude.

• Downloads are not users. CI pipelines, mirrors and Docker builds download packages thousands of times a day. Treat the number as relative, useful for comparing libraries, not as an install base.
• downloadsLastMonth is npm's own total, gaps included. It is left as the registry reports it, which means it understates by roughly the number of missing days. dailyAverage is computed on published days only and is the more honest figure.
• A trend needs at least two full weeks. Below that, trendPct is empty rather than noisy. Choose last month or longer.
• The three scores are npm's, not ours. Their methodology is npm's and changes without notice.
• Scoped packages sometimes miss download data. @scope/name is supported, but the batch download endpoint is less reliable for them.
• Package names are exact. No fuzzy matching — solid-js is not solidjs. Unknown names are reported in the status message rather than dropped in silence.
• PyPI is not covered. Its download statistics sit behind a service that rate-limits hard, and half-reliable numbers are worse than none.

---

How much does it cost?

You pay per package returned: $0.006 each, that is $6.00 per 1,000. There is no start fee, and subscription plans pay less per package.

The example input below asks for up to 100 packages, so it costs $0.60 at most.

If a run reaches the spending limit you set, the output stops at that limit and never goes past it. You are never charged for rows that were not delivered.

Use npm Downloads Scraper as an API

Call it from your own code with the Apify client, here in Python:

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")
run = client.actor("DataIO/npm-registry-download-trends").call(run_input={
    'packages': ['react', 'vue', 'svelte', 'solid-js'],
    'period': 'last-month',
    'maxItems': 100,
})
for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(item)

It also works from JavaScript, Make, Zapier, n8n, and from AI agents through the Apify MCP server.

Other actors you might like

• WordPress Plugin Scraper: Installs & Ratings
• crt.sh Subdomain Finder: Certificate Search
• Domain Expiry Checker: RDAP Registrar & Status

FAQ

Is it legal to use this data?

The actor reads public data from its official source, without logging in and without bypassing any access control. What you do with the data, for example contacting people listed in it, is your responsibility under the laws that apply to you, such as GDPR in Europe.

Can I run it on a schedule?

Yes. Create a schedule in Apify Console, daily or weekly for example, and each run delivers a fresh dataset, which you can send by email, webhook or integration.

Can AI agents use it?

Yes. It is available through the Apify MCP server, and every input field is described in its input schema, so an agent can call it directly.

Source

The public npm registry (registry.npmjs.org) and its download API (api.npmjs.org). No authentication. This Actor is not affiliated with npm or GitHub.