Scrapfly Antibot-Detector: what is protecting this page?

A toolbar badge that counts the defences

The Scrapfly Anti-bot Detector is a free Chrome extension that shows how a website protects itself from automated traffic. You browse as you normally would, the number on the toolbar icon tells you how many protections the page uses, and the popup lists each one with its confidence, its difficulty and the signals that gave it away. The framing is diagnostic rather than adversarial, and the project says so. It was built at Scrapfly because every scraping project starts with the same question, what is protecting this page, and it is just as useful for checking how your own site's bot protection looks from the outside, or for security research. The identification list covers the systems you would expect, with Cloudflare, Akamai, DataDome, reCAPTCHA, hCaptcha and Shape Security named in the project description, and the extension recognises 70 technologies out of the box, which is 30 anti-bot systems, 19 CAPTCHAs and 21 browser fingerprinting techniques.

Every detector is a JSON file you can read

The design decision that makes this more than a badge counter is that each detector is a plain JSON file that you can read, change or extend. Nothing about adding a vendor requires touching code, and the extension itself has no build step and no runtime dependencies, so the whole codebase is what you see in the repository. The detection files live in a detectors directory, with the surrounding pieces in clearly named folders for the background worker, the content scripts, the modules, the utilities and the sections that make up the popup. There are two content scripts, one ordinary content.js and one content-main-world.js, the latter being how the extension reaches page scripts where fingerprinting hooks live. The manifest and the popup are plain files at the root, and the interface strings live in a _locales directory, which the interface language list in Settings reflects, 22 languages with their flags.

Eight methods, from the address bar to the request body

When a page loads, the extension gathers what the page reveals about itself and checks it against every enabled detector, and each detector combines up to eight methods. The URL method looks at the page address, script sources and every network request, with a Turnstile API script as the example signal. Cookies covers the cookies the site sets or sends, HttpOnly ones included, with _abck for Akamai and datadome as examples. Headers reads response and request headers, with x-kpsdk-ct for Kasada. Content reads the page's HTML and the code of its inline and loaded scripts. DOM matches elements by CSS selector, for example .cf-turnstile[data-sitekey]. Window properties covers the objects scripts add to window, such as grecaptcha.render. JavaScript hooks look at calls to browser APIs commonly used for fingerprinting, such as HTMLCanvasElement.prototype.toDataURL. And payload inspects the bodies of POST, PUT and PATCH requests, optionally filtered by URL and method, along with the responses of the URLs a rule names, with sensor_data for Akamai and a proof-of-work payload as examples.

Confidence separates a name mention from proof

The scoring model is the part to understand before you quote a result. Each rule has its own confidence, and detectors define combinations of rules that score higher together. A script that only mentions a vendor's name scores between 5 and 10 percent. A signal only that vendor's product produces, its own script host, its own cookie, its own challenge endpoint, is proof and scores 100 percent on its own, and so does a vendor's complete integration, meaning its script together with its cookie, widget frame or challenge request. Shared or generic signals sit between 15 and 90 percent. The number shown for each detector is its strongest single rule or combination, and the page also gets a difficulty rating of Low, Medium or High, which is what sets the colour of the toolbar badge. In practice this means a low confidence match is a hint to investigate and a full score is a statement about the page.

Three ways to install it

The simplest option is the Chrome Web Store, where Chrome keeps the extension up to date. If you would rather not depend on the store, each version on the releases page has a ready-to-load zip attached. You download the zip and extract it into a new folder, open chrome://extensions, turn on Developer mode in the top right, then click Load unpacked and choose that folder. From source there is no build step at all, so you clone the repository and load the folder as it is:

git clone https://github.com/scrapfly/Antibot-Detector.git

then follow the same two extension page steps, choosing the cloned folder. The development loop is correspondingly simple. After editing a file you press the reload button on the extension's card in chrome://extensions and reload the page you are testing. The project ships an llms.txt file, which is a convention for giving language models a text summary of a repository, and a CHANGELOG that the project links as its what is new page, so you can see what changed in a given release before you install it.

Rules update ahead of the extension

The release notes mention a detail that matters more than it sounds. New rules ship with each release of the repository, so Rules, then Update can install them before Chrome updates the extension itself. That matters because a new anti-bot vendor appears on the site you are targeting long before the store review cycle delivers a new version of the extension, and if the only way to get the new detection is to wait for a store rollout, you are blind in the meantime. The Rules tab in the popup is where that lives, and the screenshot in the documentation shows a search for Cloudflare returning detector cards with their category, detection methods, version and an on and off switch, which means you can disable a detector that produces false positives on a particular site rather than turning the whole extension off.

Verification scripts instead of a build chain

The package metadata describes the project as a Scrapfly MV3 extension with verification scripts, no build step and no runtime dependencies, and the script list shows what that means in practice. There is a check:syntax script, a check:structure script that validates the repository layout, check:locale and check:locale-quality for the translated strings, check:rule-i18n for the detector descriptions, and check:store-listing plus check:store-images for the Chrome Web Store submission. The test script runs node --test over the test files, and a verify script chains all of those checks together with the tests, so a single command covers the whole gate. Alongside them sit a long list of end-to-end scripts, e2e:updater, e2e:methods, e2e:settings, e2e:editor, e2e:refactor, e2e:languages, e2e:history and e2e:live, each aimed at one part of the interface. The extension is on version 3.0.1, the tags are v2.8.9 on 2026-10-16, v3.0.0 on 2026-10-19 and v3.0.1 on 2026-10-20, and the last push was on 2026-10-20 with the repository not archived. The licence is the non-commercial NPOSL-3.0, which is the restriction to keep in mind, since the project metadata records a custom licence that GitHub cannot classify.

Editorial conclusion

Adopt the Antibot-Detector if you start a scraping project and need to know which protection stands in front of a page, or if you want to see your own bot defences from the outside. Do not read the confidence numbers as proof, since a vendor name in a script scores low, and check the NPOSL-3.0 terms in the LICENSE file before you reuse the detector rules in your own tooling.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. scrapfly/Antibot-Detector on GitHub