Key differences: Vercel BotID vs Arcjet
Vercel BotID vs Arcjet is a bot-detection comparison. Teams looking for a Vercel BotID alternative usually want allow/deny by bot category, inspectable decisions, and bot detection for Next.js that isn't tied to Vercel hosting.
BotID issues a token in the browser and verifies it server-side on a protected Vercel route. Arcjet bot detection runs in your request handlers: classify known bots by name and category, layer advanced client signals (headless and browser-environment anomalies, a continue cookie that persists the client signal) with IP reputation and filters, and log or act on a structured reason. Operational HTTP rules for bots, Shield, filters, and fixed-window or sliding-window rate limits change in the Arcjet dashboard or through MCP and take effect immediately, still inside the application. Token-bucket and email rules stay in code.
Allow or deny by category
Arcjet rules can vary by request context: allow a search-engine bot on a content route, deny it on a signup, change a rate limit by plan. The decision includes a structured reason that you can log or act on. BotID has no allow/deny configuration; for verified bots you can branch in code on the verifiedBotName returned by checkBotId(), but unverified bots come back as a plain boolean.
Advanced client signals vs Deep Analysis
Arcjet advanced signals run a WebAssembly module in the browser, persist a continue cookie, and evaluate with server-side bot classification and an optional missing-cookie filter. Each rule can run live or in dry-run. Vercel BotID Deep Analysis (powered by Kasada) is a similar in-browser check. It's Pro at $1 per 1,000 checkBotId() Deep Analysis calls; Enterprise pricing is custom. It issues a per-request token, not a persistent signal that you can enforce as a filter, and the result is essentially a boolean plus limited verified-bot fields.
Forms and integration
You call bot detection from any request handler, including native HTML form POST requests. BotID is a client script plus a server check. You list protected paths separately from the handler. Native HTML form POST requests aren't supported, so you must refactor your forms.
Hosting
Arcjet runs on any host for JavaScript, TypeScript, and Python, including bot detection for Next.js on Vercel, elsewhere, or locally with the same behavior as production. BotID works only for JavaScript and TypeScript applications hosted on Vercel. In local development it returns not-a-bot, and development options can bypass or override that result.
Vercel's WAF and rate limiting are separate products that you configure independently. Arcjet runs bots, rate limiting, Shield WAF, email validation, filters, and IP reputation in the same request-handler call.
Comparison
| Area | Arcjet | Vercel BotID |
|---|---|---|
| What it is | Bot detection in request handlers: known bots by name and category, optional advanced client signals, filters, and IP reputation. Inspectable decision. | Browser token plus server verification on a protected Vercel route. Essentially a boolean plus limited verified-bot fields. |
| Hosting | Any host, including Next.js on or off Vercel. | Vercel only. |
| Local development | Same behavior as production. | Returns not-a-bot locally; development options can bypass or override. |
| Integration model | Call from code in any handler. | Client script plus server check. Vercel lists protected paths separately. |
| HTML forms | Works with native forms and any HTTP request. | Native HTML form POST requests aren't supported. |
| Configuration | Allow or deny bots by name and category. Filter rules compose cookie, header, IP, and geo conditions. Operational bot, Shield, filter, and fixed-window or sliding-window rate-limit rules change in the Arcjet dashboard or through MCP immediately. Token-bucket and email rules stay in code. | Minimal configuration. No allow/deny list for named bots. Server API is essentially a boolean plus limited verified-bot fields. No filter rule language. |
| Advanced bot signals | Browser WebAssembly signals, continue cookie, live or dry-run, inspectable reason. Usage maps to bot-detection calls, not script loads. | Deep Analysis (Pro $1 per 1,000 server checks; Enterprise custom): per-request token, boolean result, no persistent filter signal. |
| Layered with | Rate limiting, Shield WAF, email, filters, and IP reputation in the same request-handler call. | WAF and rate limiting are separate Vercel Firewall products. |
| Pricing (bot feature) | See the pricing page. Arcjet doesn't bill for signals script loads. | Basic analysis: free on all plans. Deep Analysis: Pro $1 per 1,000 server checks; Enterprise custom. |
Layered bot detection
BotID reports whether an inbound HTTP client looks automated. That's the same job as Arcjet bot detection in request handlers: stop scrapers, credential stuffing, and other clients that target /login or a signup.
Arcjet layers that decision. Arcjet can deny a request because signals look automated, because the user agent matches a known scraper, or because the IP has a poor reputation. A missing continue cookie is itself a signal that you can filter on. Live or dry-run applies per rule. HTTP request checks can fail open when your application can't reach the Cloud API. That behavior is configurable.
Bot detection is an HTTP control in request handlers.
When to choose which
Choose Arcjet
Choose Arcjet if any of the following apply:
- You want a Vercel BotID alternative that isn't tied to Vercel.
- You need native form support.
- You want allow or deny by bot category with inspectable decisions.
- You need to test locally with production behavior.
- You want advanced client signals without a per-check Deep Analysis bill.
- You want filter rules and IP reputation in the same bot decision.
Choose BotID
Choose BotID if any of the following apply:
- You're fully on Vercel.
- You want a boolean bot check.
- You don't need to choose which bots to allow.
- You're content to configure rate limits and WAF separately in the Vercel Firewall.
Compare: Vercel WAF vs Arcjet · CAPTCHAs vs Arcjet · All comparisons
Frequently asked questions
Does BotID work without Vercel?
No. Vercel BotID requires hosting on Vercel. Arcjet runs on any host, including Next.js on or off Vercel, and in local development.
How does Arcjet layer bot detection compared with BotID?
BotID verifies a browser-issued token on a protected Vercel route and returns an essentially boolean result. Arcjet classifies known bots by name and category in your request handlers, layers advanced client signals (headless and browser-environment anomalies, a continue cookie) with IP reputation and filters, and returns an inspectable reason. HTTP request checks can fail open when the Cloud API is unreachable. That is configurable. Bot detection stays on HTTP.
Can I configure which bots to allow or block?
With Arcjet you can allow or deny bots by name and category in your request handlers. For example, allow search-engine crawlers and block the rest. Vercel BotID has no allow/deny configuration, but checkBotId() returns verified-bot fields (verifiedBotName, verifiedBotCategory) synchronously, so you can branch in code for verified bots; unverified bots come back as a plain boolean.
Does BotID work with native HTML forms?
Vercel documents that native HTML form POST is not supported; forms have to be refactored. Arcjet bot detection is called from code in any request handler, including native form POST.
Bot detection in your request handlers
Protect your application with Arcjet
Get allow/deny by bot category, inspectable decisions, and advanced client signals, on Vercel or any other host.