How to Detect Live Chat and Chatbot Tools on a Website

To detect the live-chat or chatbot tool a website uses, open the DevTools Network tab and reload: chat widgets load a script from their provider's domain, so a request to widget.intercom.io means Intercom, js.driftt.com means Drift, and static.zdassets.com means Zendesk. Even quicker, right-click the chat bubble itself and choose Inspect — the widget is almost always an iframe whose origin names the provider directly. This works because chat tools are client-side widgets injected into the page, so they announce themselves the moment they load. This guide covers the fingerprints for the major chat vendors, how to handle widgets that load lazily, and what the chat tool reveals about a company.

It is a focused companion to how to find out what technology a website uses and pairs well with how to find what email marketing platform a website uses, since both are parts of a company's go-to-market stack.

Why detect a site's chat tool?

The chat or chatbot widget a company runs is a quietly informative signal. For sales — especially if you sell support, sales-engagement or conversational software — it identifies the incumbent and a possible switching opportunity. For competitive research, the chat tool shows how a rival handles support and sales conversations and how much they invest in them. For stack mapping, the chat vendor often reveals the broader platform behind it — a Zendesk chat suggests Zendesk for support, a HubSpot chat points to the HubSpot ecosystem. And for qualification, the presence and sophistication of a chat tool is a proxy for a company's maturity and budget. Because these widgets are client-side, all of this is readable from the outside.

Method 1: watch the Network tab

The most thorough method is to watch what loads. Open DevTools (F12), go to the Network tab, and reload. Chat tools fetch their widget code from the provider's CDN, so the request stands out by domain: widget.intercom.io, js.driftt.com, static.zdassets.com, code.tidio.co, client.crisp.chat, and so on. Because some widgets load lazily — after a delay, on scroll, or when the page goes idle — keep watching for a few seconds and interact with the page; the provider request will fire when the widget initialises. The Network tab is the most reliable approach precisely because it catches these deferred loads that a quick source view would miss.

Method 2: inspect the chat bubble

If the chat bubble is visible, the fastest single check is to inspect it. Right-click the bubble (or the open chat window) and choose Inspect. Chat providers render their widget inside an iframe to isolate it from the host page, and that iframe's src origin points straight at the provider — client.crisp.chat, widget.intercom.io and the like. Reading the iframe origin names the tool directly, with no need to trace the loading script. The surrounding DOM often carries provider-specific IDs and classes too (for example an intercom- prefixed container), which corroborate the identification.

Method 3: View Source

A source check is quick for most tools. View the page source (Ctrl/Cmd + U) and search for the provider's domain or its initialisation snippet — chat tools are usually installed via a small inline script that references the vendor. This catches widgets that load eagerly and is fast to run. The caveat is the lazy-loading one again: a widget injected only after the page settles may not appear in the raw source, so if the source search comes up empty but you can see a chat bubble, fall back to the Network tab or inspect the bubble.

The fingerprint table

Chat / chatbot tool	Tell-tale domain / marker
Intercom	widget.intercom.io, js.intercomcdn.com, intercomSettings, intercom- DOM
Drift	js.driftt.com, drift.com, drift object
Zendesk Chat / Messaging	static.zdassets.com, zopim, Zendesk Web Widget
Tidio	code.tidio.co, tidioChatApi
Crisp	client.crisp.chat, $crisp object
LiveChat	cdn.livechatinc.com, LiveChat widget
HubSpot Chat	js.hs-scripts.com / HubSpot conversations widget
Tawk.to	embed.tawk.to

A single matching domain settles the question; the iframe origin confirms it visually.

Help centres, knowledge bases and AI answer widgets

Beyond the classic live-chat bubble, a growing category of widgets is worth recognising because they often sit right alongside chat. Help-centre and knowledge-base widgets — Zendesk's Help Center, Intercom's Help Center, HelpScout's Beacon, Gorgias for ecommerce — embed searchable documentation and frequently launch from the same corner of the screen as a chat bubble. AI answer assistants are increasingly common too: tools that answer support questions automatically from a knowledge base, sometimes branded, sometimes white-labelled, and detectable by their own script domains and API calls in the Network tab. The practical point is that what looks like a single "chat" button may actually be a combined messaging-plus-help-centre experience, and the underlying vendor (HelpScout's Beacon, for instance) may differ from your first guess. So when you inspect the widget, read the iframe origin and the loaded scripts carefully rather than assuming the bubble is a pure live-chat tool — the distinction between live chat, self-service help and AI answering matters for understanding how a company actually handles support.

A worked example

You want to know how a SaaS competitor handles conversations. You load their site, open the Network tab, and within a couple of seconds see a request to widget.intercom.io followed by js.intercomcdn.com — Intercom is loading. A moment later the familiar chat bubble appears bottom-right; you right-click it and Inspect, and the widget is an iframe with a widget.intercom.io origin, sitting inside an intercom-container element. That confirms Intercom beyond doubt. You also notice the page set an intercomSettings object in the source with an app ID, the standard Intercom install. So the read is clear: this company runs Intercom for sales and support chat — an enterprise tool that signals a well-resourced, growth-focused operation. In under a minute you have both the vendor and a meaningful inference about their maturity.

What the chat tool reveals about a company

The chat vendor is a useful proxy for maturity and intent. A site running an enterprise conversational platform like Intercom or Drift is investing in chat-driven sales and support, which usually means a well-funded, growth-oriented team with the budget for premium tooling. A free or lightweight widget (a basic Tawk.to or a free Crisp tier) suggests a leaner or earlier-stage operation. The specific tool also hints at the broader stack: Zendesk chat usually means Zendesk for support tickets, HubSpot chat points to the HubSpot CRM and marketing suite, and Drift historically signals a sales-led, account-based motion. And the simple presence of a serious chat tool tells you the company prioritises real-time engagement, while its absence on a sales-heavy site is itself notable. For qualification and competitive research, that is a lot of insight from one widget.

Chatbots versus live chat

It is worth distinguishing what the widget actually does, because the same tool can be configured for either. Live chat connects the visitor to a human agent; chatbot or automation flows respond programmatically, qualify leads, or deflect support questions before (or instead of) involving a person. Many modern tools (Intercom, Drift, HubSpot) do both, and an increasing number now add AI-driven answering on top. From the outside you can reliably detect the vendor and often tell whether a bot greets you automatically, but you cannot always see how the automation is configured or whether humans are staffing it behind the scenes. So report the tool with confidence, and treat finer claims about how it is run as inference rather than fact.

Check more than the homepage

One tactic improves accuracy noticeably: do not judge the chat stack from the homepage alone. Many companies scope their chat widget to specific pages — a sales chatbot on pricing and product pages, a support widget inside the logged-in app or the help centre, and perhaps nothing on the blog. So a homepage that shows no bubble does not mean there is no chat tool; the pricing page or the contact page may load one, and the in-app experience may load a different one entirely. Likewise, a tool present on the marketing site might be configured for sales there but support elsewhere. Sampling a few representative pages — homepage, pricing, contact, and a help or docs page if one exists — gives a far more complete read than a single page, and it is the same "check more than one resource" principle that makes the rest of technology detection reliable. A couple of extra page loads is cheap insurance against a misleadingly empty first impression.

The limits: client-side widget only

The honest caveat: detection sees the client-side widget a site loads, which reliably identifies the chat vendor. What it does not see is the configuration and operations behind it — how the tool is set up, which automations run, how many agents staff it, the response times, or whether it integrates with a CRM you cannot observe from the front end. A site could load Intercom but barely use it, or run a sophisticated bot you only partly experience as a visitor. So treat the detected vendor as solid, and anything about how well or how much it is used as an inference from the visible behaviour. This is the same client-side boundary that applies across detection, including analytics detection.

How accurate is chat detection?

Highly accurate for the vendor. Chat widgets load identifiable scripts and render in provider-origin iframes, so naming the tool is reliable across the major vendors. The two things to watch are lazy loading — wait and interact so deferred widgets initialise before you conclude there is none — and the configuration boundary, where you can see the tool but not how it is run. So "which chat tool does this site use?" is a question you can answer with confidence; "how is it configured and staffed?" is largely invisible from outside. Catch the lazy loaders and report the vendor, and your detection will be both accurate and honest about its limits.

The workflow

1. Open the Network tab and reload; watch for provider domains like widget.intercom.io.
2. Wait and interact so lazy-loaded widgets initialise.
3. Inspect the chat bubble to read the iframe origin and confirm the vendor.
4. View Source for the install snippet and provider domain.
5. Report the vendor confidently; treat configuration and staffing as inference.

Go deeper

• The whole stack: how to find out what technology a website uses.
• The email side of the stack: how to find what email marketing platform a website uses.
• Qualify with the signals: what is technographics?
• The measurement layer: how to find out what analytics a website uses.

Want the chat tool, marketing stack and full technology picture in one report? Analyse any site with StackOptic — free, no sign-up.