isbot recognises the crawlers that say who they are, and nothing else

Good bots, bad bots, and what the package promises

The definitions section sets out three categories. A bot is an autonomous program imitating or replacing some aspect of human behaviour, performing repetitive tasks much faster than human users could. A good bot is an automated program that visits websites in order to collect useful information, and web crawlers, site scrapers, stress testers and preview builders are welcomed on most websites because they serve purposes of mutual benefit. A bad bot is a program designed to perform malicious actions, ultimately hurting businesses, such as testing credential databases, DDoS attacks and spam bots. And then the clarification that decides what the package is for. This package aims to identify good bots, those who voluntarily identify themselves by setting a unique, preferably descriptive, user agent, usually by setting a dedicated request header. What it does not do is try to recognise malicious bots or programs disguising themselves as real users. That boundary is the whole design, and it is a much more useful contract than a package that claimed to detect bots in general.

Nine named exports, and only one of them is a boolean

The package installs from npm and the API is a table of ten named imports, and the shape of it is more interesting than a single function:

npm i isbot

import { isBot } from "isbot";
isBot(navigator.userAgent);

isBot takes a string and returns a boolean, and isBotNaive does the same with a naive pattern, which the table marks as less accurate. getPattern returns the regular expression used to identify bots, and list returns a string array of all individual pattern parts, which is the list you manipulate when you want to change the behaviour. findBotMatch returns the substring matched by the regular expression, findBotMatches returns all of them, findBotPattern returns the regular expression used to identify a bot substring, and findBotPatterns returns all of those regular expressions. And then the two constructors, createIsBot takes a regular expression and returns a function, and createIsBotFromList takes a string array and returns a function. The distinction between the match functions and the pattern functions is the useful one, because it lets you ask not only whether a user agent is a bot but which part of it gave it away, which is what you need when you want to exclude one specific tool.

One regular expression, rebuilt from maintained lists

The accuracy section explains the mechanism, and it is a good design. isBot is an asset when it can most accurately identify bots by the user agent string, and it uses expansive and regularly updated lists of user agent strings to create a regular expression that matches bots and only bots. Above everything else, it is maintained by a community of contributors who help keep the list up to date. So the package is not a regex you can read and trust forever, it is a generated artefact whose source of truth is a list, and the list is a wiki of bot signatures that people add to as new crawlers appear. The maintenance script in the package.json reflects that, with a maintenance entry that runs npm update, then the prepare step with a force flag, then the format step and the tests. The data comes from external sources on top of the project's own lists, and the fixtures/ and tests/ directories are where the accuracy claims are checked.

The fallback path and what it costs you

There is one environment problem, and the documentation deals with it explicitly. The pattern uses lookbehind methods which are not supported in all environments, so a fallback is provided for environments that do not support lookbehind, and the fallback is less accurate. The test suite includes a percentage of false positives and false negatives which is deemed acceptable for the fallback, and the numbers are 1% false positive and 75% bot coverage. Those two figures describe the trade precisely. A quarter of the bots in the wild are not recognised by the fallback, so an application relying on it will serve cached content to some crawlers and treat others as visitors, and one in a hundred real users is classified as a bot, which for an analytics pipeline means a small, constant error that has to be understood rather than discovered. The main path is the accurate one, so the practical question is which runtimes you support, and Node 18 or newer is the stated engine requirement in the package metadata.

Adjusting the list, in both directions

The helper functions exist so you can change the list without forking the package, and the documentation gives two worked examples. The first creates a custom isBot that does not consider Chrome Lighthouse user agents to be bots, by taking a set of Lighthouse user agent strings, mapping each through findBotPatterns to get the patterns to remove, filtering the list, and building a new function with createIsBotFromList. The second creates a custom isBot that considers another pattern a bot, which is not included in the package originally, with a single call to createIsBotFromList on the list concatenated with the extra string. The second example is short enough to be the whole story of the API's flexibility, and it is worth noticing what it is for, since a tool that identifies itself with a distinctive marker can be added to the list without waiting for a release. The first example is the harder case, because excluding a tool means finding all the patterns that match it, and findBotPatterns exists precisely for that.

Do not whitelist on a user agent header

The reasons section is short and the advice is firm. Recognising good bots such as web crawlers is useful for multiple purposes, and although it is not recommended to serve different content to web crawlers like Googlebot, you can still elect to flag pageviews to consider with business analysis, prefer to serve cached content and relieve service load, and omit third party solutions' code such as tags and pixels to reduce costs. And then the warning that is the most important sentence in the README for anyone building on this package, that it is not recommended to whitelist requests for any reason based on user agent header only, and that other methods of identification can be added such as reverse DNS lookup. The reasoning is not subtle, since a user agent is a claim rather than a proof, and any system that grants access based on a claim has granted it to whoever writes the claim. The package is a classifier for measurement and for cost control, and the documentation wants it used that way rather than as an access control.

Unlicense, a browser build and a CommonJS default

The packaging is arranged so the same code can be used in a server, in a bundler and in a browser without a build step. The package metadata gives the version as 5.2.2, the licence as Unlicense, the engines requirement as node 18 or newer, and the type as commonjs with a main of ./index.js and a module of ./index.mjs, plus a browser field pointing at the ESM build and a jsdelivr field pointing at ./browser.global.js, with the exports map resolving import to the .mjs and require to the .js for both the browser and the node conditions. The browser usage is the ESM script tag importing from the CDN at https://cdn.jsdelivr.net/npm/isbot@5/+esm, and there is a UMD variant at https://cdn.jsdelivr.net/npm/isbot@5 that makes isBot a global. The Unlicense is worth noting because it is the most permissive licence there is, so there is no attribution requirement to argue about, and the repository ships a LICENSE file, a SECURITY.md, a CHANGELOG, a CONTRIBUTING guide and a code of conduct. The last push was on 2026-10-01 and the project has no GitHub releases, so the npm version is the version marker.

Editorial conclusion

isbot is the right tool when you want to tell a search crawler from a visitor for analytics, for serving cached content, or for omitting third party tags, because it is a maintained list rather than a regex you wrote once and forgot, and because the API lets you adjust the list when a tool you care about is misclassified. It is the wrong tool for bot defence, since it says nothing about programs that hide, and the README is explicit that it is not recommended to whitelist requests for any reason based on the user agent header alone, suggesting reverse DNS lookup as an additional method. Before you adopt it, read the clarifications, because the package is deliberately not a security control, and if you rely on the fallback path in an older runtime, look at the stated cost of it, which is one percent false positives and seventy-five percent bot coverage.

Frequently asked questions

Official sources

1. Issues
2. License: Unlicense
3. omrilotan/isbot on GitHub
4. Project website
5. README