Return YouTube Dislike: Restoring the Dislike Count in Chrome and Firefox

The API field Google deleted, and what replaced it

On November 10th, 2021, Google announced that the YouTube dislike count would be removed from public display. The README records a second step: the `dislike` field in the YouTube API was removed on December 13th, 2021. That second change matters more for anyone building on top of YouTube, because it removed the underlying number, not just the place it was rendered. A dislike count is a public signal about whether a video delivers what its title promises, and the extension exists to put that signal back in the interface.

The audience is narrow and specific. This is for people who watch YouTube in a desktop browser and want a number under the video, not a research tool and not a moderation system. The README also points to a userscript build for browsers that are not Chrome or Firefox, which widens the reach beyond the two store listings without turning the project into a general-purpose YouTube client.

Scraped numbers plus extrapolated estimates, and why the output is a guess

The README is direct about the mechanism: with the API field gone, the backend switched to a combination of scraped dislike stats and estimates extrapolated from extension user data. Read that sentence carefully, because it describes two different data sources joined into one displayed number.

Scraping covers what can still be observed publicly. Extrapolation covers the rest, using the behaviour of people who have the extension installed as the sample. The consequence is that the figure you see is a model output, not a measurement. On a video with heavy extension usage the estimate can track reality closely; on a video with little or no extension usage, the estimate has almost nothing to work from. The `/votes` endpoint in the README returns both `dislikes` and `rawDislikes` alongside `rawLikes`, which is a hint that the served figure and the raw collected figure are not the same thing. The README does not explain how the two are reconciled, and that gap is worth knowing about before you treat the number as fact.

The project exposes the same data through an open API at `https://returnyoutubedislikeapi.com`, documented through a Swagger page. Third-party use is allowed with two conditions stated in the README: clear attribution with a link to returnyoutubedislike.com, and respect for per-client rate limits of 100 per minute and 10,000 per day, which return a 429 status code when exceeded. A non-existent video ID returns 404 and a malformed one returns 400.

Installing the extension and reading your first dislike count

The README does not walk through installation, because for most users it happens through a store listing rather than a terminal. The Chrome Web Store entry is linked in the README badges, and the Firefox add-on lives on addons.mozilla.org under the name return-youtube-dislikes. Install from the store, reload any open YouTube tab, and the dislike figure appears next to the like count under the player.

Building from source is a different path, and the repository states the toolchain requirements explicitly in `package.json`: Node 22.17.0 and npm 10.8.2, with `[email protected]` declared as the package manager. If your local Node differs, expect the build to complain. The scripts are the usual pair.

npm install
npm run build

The README does not document where the built extension lands or how to load it as an unpacked extension, so check the repository's contributing guide before assuming a directory. For development there is a watch mode:

npm run dev

If you want the userscript rather than the extension, the repository ships a separate build target and a verification step for the artifact:

npm run build:userscript
npm run check:userscript-artifact

The `check:userscript-artifact` script runs `node Extensions/e2e/verify-userscript-artifact.js`, which the package scripts define. That is a build-integrity check, not a functional test of the extension inside a browser. The project also carries Playwright configurations for extension and userscript end-to-end runs, so the test surface is broader than a unit suite, but the README does not describe how to run those against a signed-in YouTube session.

If you would rather consume the data yourself, the API needs no key. The README gives this endpoint for the votes of a given YouTube video ID: `/votes?videoId=kxOuG8jMIgI`, against the base URL `https://returnyoutubedislikeapi.com`. The README gives the response shape: fields including `id`, `likes`, `rawDislikes`, `rawLikes`, `dislikes`, `rating`, `viewCount` and `deleted`. A malformed ID returns 400 and an unknown one returns 404, so handle both rather than assuming every response carries a payload.

Where the estimate breaks and when to use something else

The honest limitation is baked into the design. Because part of the number comes from extrapolating extension user data, the accuracy of any individual video depends on how much of that video's audience has the extension installed. The README never claims the figure is exact, and it should not be read as one. Treating it as ground truth in an argument about a video's reception is a misuse.

The second limitation is dependency on a third-party backend. Every video you open produces a request to `returnyoutubedislikeapi.com`. That is a privacy trade-off, not a bug, but it is a real one: the service learns which video IDs your browser is asking about. The README does not describe any local-only mode, so if you want no external calls at all, this project is the wrong shape for you.

The third is platform scope. The README frames the extension as a Web Extension for Chrome and Firefox, with a userscript for other browsers. It does not describe a native mobile client, so a phone browser is not a supported target in the documented material. Anyone searching for an Android or iOS build should expect to find nothing official here.

Finally, there is the failure mode users report most often in the wild: the extension appears installed but shows nothing. The README does not document a troubleshooting procedure, so the first thing to check is whether the extension is enabled and whether YouTube's own layout changes have broken the injection point. That last part is a recurring cost of building on top of a site you do not control.

How this differs from the YouTube Data API and from no extension at all

The obvious alternative is the YouTube Data API itself, and the difference is not a matter of preference. The `dislike` field was removed from that API on December 13th, 2021, so an application built on the official API cannot retrieve a dislike count at all. Return YouTube Dislike exists precisely because that route is closed. If your requirement is an officially sanctioned number, no tool satisfies it, and that is the point.

The second alternative is doing nothing, which is what most viewers do. The cost of that choice is the loss of a pre-watch quality signal. The cost of the extension is a backend request per video and a number you have to interpret as an estimate. Those are the two ends of the trade, and the project sits firmly on one side.

The third comparison is against the project's own API. If you are building a tool rather than watching videos, you do not need the extension at all. You need the `/votes` endpoint, attribution to returnyoutubedislike.com, and rate-limit handling for the 429 responses described in the README. That is a meaningfully different integration from installing a browser add-on, and it is the path the project explicitly permits.

Licence, forks, and the cost of keeping up with YouTube

The repository is licensed GPL-3.0, stated in the README badge and present as a LICENSE file at the top level. For most users this changes nothing. For anyone planning to ship a modified version, the copyleft terms apply to the distributed derivative, and the README's API section imposes separate conditions on third-party use of the backend: attribution and rate limits. Those are two distinct sets of obligations, and the README does not attempt to reconcile them. If you intend to redistribute a fork or build a product on the API, read the LICENSE file and the API section together rather than assuming one covers the other. This is a description of what the repository states, not legal advice.

The maintenance cost is the interesting part. The last push to the repository was on 2026-09-07, and the releases around that date show what the work actually consists of: v4.0.6 is labelled a Firefox sign-in consent fix, v4.0.5 covers a Firefox update plus Shorts fixes and a hide-clutter option, and the userscript release 3.2.0 adds Shorts support and voting. That release cadence is a direct measure of the maintenance burden. Every YouTube layout change, every Shorts redesign, every browser consent flow update is a potential break, and the project absorbs that cost on an ongoing basis. A fork inherits the same treadmill. There is no version of this project that stops needing updates while YouTube keeps shipping changes.

Editorial conclusion

Return YouTube Dislike suits people who watch YouTube in a desktop browser and want a dislike figure next to the like count, accepting that the number is an estimate rather than a measurement. It is the wrong tool for anyone who needs an authoritative figure, since the YouTube API field it once relied on was removed on December 13th, 2021, and for anyone unwilling to send video IDs to a third-party backend. Before installing, open the extension's permissions list in the store listing and confirm you accept the host access it requests.

Frequently asked questions

Official sources

1. Anarios/return-youtube-dislike on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases