A captcha is the bluntest anti-abuse tool there is. It works, in the sense that it stops scripted submissions, and it costs you real visitors, in the sense that some of them will fail it, be confused by it, or never see it load at all. Both halves of that trade are worth understanding before you tick the box, because the box is easy to tick and the cost is invisible in your reports.
Two switches, and they are not the same risk
There is no single captcha setting. There are two, on two different screens, and they protect two different things.
On the pre-chat screen the control reads Require Google reCAPTCHA before visitors can start a chat. On the offline message screen it reads Require Google reCAPTCHA before visitors can send offline messages, with a note that the inline chat uses the same setting. Both are off unless you turn them on, and turning one on does nothing to the other.
The two are not equally safe to enable. An offline message is a single submit: the visitor fills a form, meets a challenge, sends once, and is done. Starting a chat is a conversation that keeps talking to our servers for as long as it lasts. That makes the pre-chat switch the heavier of the two, and it is the one to test end to end on your own site before you leave it on for real visitors. Start a chat yourself from a normal browser, hold the conversation for a few minutes, and confirm it stays connected. If you only need to stop junk arriving from a form, the offline switch is the one you want, and it is the one this guide recommends starting with.
You do not supply any keys. The captcha keys belong to the platform, not to your account, so there is nothing to register with Google and nothing to rotate. The flip side is that you cannot use your own reCAPTCHA account or see the challenge statistics Google would show its own key holders.
What the visitor actually meets
The challenge is the familiar tick box: I am not a robot, sometimes followed by an image puzzle when Google is unsure. What surprises most people the first time is where it appears. It is not drawn inside the chat window. It is a small white panel that docks in the bottom left corner of the page, above everything else, and it shows up when the form it belongs to is in play.
That placement is worth knowing before a colleague reports it as a bug. It also means the challenge sits on your page, in your visitor's eyeline, next to whatever else lives in that corner. If you have a cookie banner or a back-to-top button in the same place, look at the result on a real page before you decide you are happy with it.
When the visitor submits without ticking the box, they get a browser alert rather than an inline field error. The wording is fixed: Please complete the captcha challenge. If the tick was made but the server check does not pass, the wording is Captcha verification failed. Please try again. Neither sentence is part of the text you can rewrite for your site, so unlike the name and email prompts on the same form, they will not follow you into another language.
The visitor who cannot reach Google
The challenge is Google's, loaded from Google. That is fine for most of the world and not fine for some of it. A content blocker, a strict corporate proxy, a school network or a country that cannot reach Google will all produce the same outcome: the panel waits about fifteen seconds, then says the captcha could not load and suggests checking content blockers.
At that point the visitor cannot proceed. The design fails closed on purpose, which is the correct choice for a security control and a genuinely bad outcome for a customer who only wanted to ask a question. There is no bypass to offer them and no fallback form.
So the honest way to think about the captcha is as a filter with a false positive rate you cannot see. Nobody reports the message they did not manage to send. If your audience skews towards technical users, privacy-minded people, or regions where Google services are unreliable, that rate is higher than you would guess, and it argues for leaving the captcha off until you actually have an abuse problem. Our advice on handling spam and time wasters covers the cheaper measures to try first.
One challenge, one attempt
A completed challenge produces a single-use token. Our server sends it to Google along with the visitor's address for verification, and clears it whether the answer was yes or no. One tick, one attempt.
The practical consequences are small but real. A visitor who ticks the box, then wanders off to find their order number, then comes back and submits may find the challenge has gone stale and needs doing again. A submission that fails validation for another reason has spent the tick as well. Neither is a disaster, but both add a step to somebody who was already prepared to fill in a form for you, which is why the fewest-fields principle from pre-chat form design matters more once a captcha is in play, not less.
It lives in the widget, so the widget has to be current
The captcha is part of the current widget runtime. Sites still embedding an earlier generation of the widget do not get the challenge, and the setting quietly has no effect for them. That is the single most important thing to check before you rely on it: if the box is ticked and you never see a challenge on your own site, you are almost certainly on an older embed rather than looking at a bug.
Our guide on telling which widget version you are running walks through the check, and moving to the current runtime is normally a matter of refreshing the embed code you paste into your pages. Do that first, then decide about the captcha. Enabling a protection that is not running is worse than leaving it off, because you will believe you are covered.
What to reach for first
Most junk that reaches a chat team is not scripted at all. It is people: sales pitches, students, the occasional time waster. A captcha does nothing about any of them, and the connection and access controls in your account are a better answer for the traffic you actually want to stop. Blocking by address, restricting who sees the widget, and giving agents explicit permission to end a conversation all cost your good visitors nothing.
Save the captcha for the specific shape of problem it solves: a form being submitted by something that is not a person, in volumes a person could not produce. That is a real problem, it does happen to offline forms, and when it happens the captcha is the right tool.
Rate limiting is the quieter member of the same family, and it is often the better first move because visitors never meet it at all. The same per-address limiter sits behind several public surfaces, including the unsubscribe page, where it is what makes bulk abuse impractical without breaking a single legitimate click — what stops someone unsubscribing your address for you walks through that trade in detail.
What to measure
Messages before and after. Count offline messages for the two weeks either side of the change. A drop in junk with a flat genuine count is the outcome you wanted. A drop in both means you are paying for it.
Complaints about not being able to send. These arrive through other channels, usually email, and they are the only signal you will get about visitors who failed the challenge. One is worth investigating, three is worth turning the switch back off.
Your own weekly check. Open a private window, load a page with the widget, and submit the form the captcha protects. It costs a minute and it catches the case where a change to your site, your consent banner, or your embed code stopped the challenge rendering.
Put it into practice
- Start with the offline switch. One form, one submit, the least that can go wrong.
- Test the pre-chat switch yourself before leaving it on, with a real conversation held for several minutes.
- Look at the corner of your page. The challenge docks bottom left, outside the chat window.
- Check your widget generation first. On an older embed the setting does nothing at all.
- Accept that it fails closed. Visitors who cannot load Google cannot contact you.
- Try the cheaper controls first if your problem is people rather than scripts.
- Re-test after any change to your embed code, your consent banner or your page layout.
A captcha is worth having available and worth being slow to enable. Turn it on when you can point at the abuse it will stop, leave it off when you cannot, and either way check what your own visitors see rather than trusting the tick box.