The hCaptcha widget can protect your applications from bots, spam, and other forms of automated abuse. Installing hCaptcha is fast and easy. It requires either adding some simple HTML and server side code, or using one of the many tools that natively support hCaptcha.
A complete list of known hCaptcha integrations is also available.
If you're already using Google's reCAPTCHA, you can use your existing code with a few slight changes. hCaptcha methods are API-compatible with reCAPTCHA methods, for example
onload(). Custom data attributes like
tab-index are also supported in the same way by hCaptcha.
You embed the hCaptcha widget on your site. For example, on a login form. The user answers an hCaptcha. They get a passcode from our server that is embedded in your form. When the user clicks Submit the passcode is sent to your server in the form. Your server then checks that passcode with the hCaptcha server API. hCaptcha says it is valid and credits your account. Your server now knows the user is not a bot and lets them log in. Pretty simple!
Content Security Policy (CSP) headers are an added layer of security that help to mitigate certain types of attacks, including Cross Site Scripting (XSS), clickjacking, and data injection attacks.
If you use CSP headers, please add the following to your configuration:
<script> must be loaded via HTTPS and can be placed anywhere on the page. Inside the
<head> tag or immediately after the
.h-captcha container are both fine.
Second, you must add an empty DOM container where the hCaptcha widget will be inserted automatically. The container is typically a
<div> (but can be any element) and must have class
h-captcha and a
data-sitekey attribute set to your public site key.
Typically, you'll want to include the empty
.h-captcha container inside an HTML form. When a captcha is successfully solved, a hidden token will automatically be added to your form that you can then POST to your server for verification. You can retrieve it server side with POST parameter
Here's a full example where hCaptcha is being used to protect a signup form from automated abuse. When the form is submitted, the
h-captcha-response token will be included with the email and password POST data after the captcha is solved.
By adding the client side code, you were able to render an hCaptcha widget that identified if users were real people or automated bots. When the captcha succeeded, the hCaptcha script inserted a unique token into your form data.
To verify that the token is indeed real and valid, you must now verify it at the API endpoint:
The endpoint expects a POST request with two parameters: your account secret and the
h-captcha-response token sent from your frontend HTML to your backend for verification. You can optionally include the user's IP address as an additional security check. Do not send JSON data: the endpoint expects a standard URL-encoded form POST.
A simple test will look like this:
Note that the endpoint expects the
application/x-www-form-urlencoded Content-Type. You can see exactly what is sent using
in the example above.
Do not use a GET request to call /siteverify. Use a POST request, and pass the parameters in the form body, not the URL.
While the endpoint may respond correctly to a GET request or to a POST request that uses URL parameters, this is not guaranteed. If the parameters you send to GET are too long, the request will fail and you will be unable to validate passcodes. Using a POST request ensures you will not have this problem.
Please note that you must call
/siteverify with your account secret in order to be credited: this is the step in the process that associates your account with the value of that answer. You will also be unable to validate passcodes from a sitekey in one account if using a different account's secret.
|secret||Required. Your account secret key.|
|response||Required. The verification token you received when the user completed the captcha on your site.|
|remoteip||Optional. The user's IP address.|
|sitekey||Optional. The sitekey you expect to see.|
Tokens can only be used once and must be verified within a short period of time after being issued. To retrieve the token on your server, use the
h-captcha-response POST parameter submitted by your form.
We recommend passing the sitekey parameter, as it will prevent tokens issued on one sitekey from being redeemed elsewhere. Depending on your difficulty settings this might have no security impact, but if you set a higher difficulty level and do not enforce sitekey matches an adversary could potentially solve an easier challenge on another sitekey, then redeem it on a harder one.
Your POST request will receive a JSON response. You should check the
success field and only execute your normal business logic if
true. Otherwise, check the
error-codes field for a human-readable error code and return an appropriate error message to the end user.
Here's what a JSON response from hCaptcha looks like:
Please note that the credit field is not always included, and that absence of a False credit flag does not guarantee credit was earned. Some example scenarios when it may appear: site visitor is using a very old browser, or has a poorer than normal history of accuracy.
Please also note that the hostname field is derived from the user's browser, and should not be used for authentication of any kind; it is primarily useful as a statistical metric. Additionally, in the event that your site experiences unusually high challenge traffic, the hostname field may be returned as "not-provided" rather than the usual value; all other fields will return their normal values.
These are the error codes that can be returned by the hCaptcha API:
|missing-input-secret||Your secret key is missing.|
|invalid-input-secret||Your secret key is invalid or malformed.|
|missing-input-response||The response parameter (verification token) is missing.|
|invalid-input-response||The response parameter (verification token) is invalid or malformed.|
|bad-request||The request is invalid or malformed.|
|invalid-or-already-seen-response||The response parameter has already been checked, or has another issue.|
|sitekey-secret-mismatch||The sitekey is not registered with the provided secret.|
If you are developing on your local machine there are a few things to keep in mind.
Modern browsers have strict CORS and CORB rules, so opening a
file://URI that loads hCaptcha will not work. Loading hCaptcha from
http://localhost/ will encounter the same issue on some browsers. The hCaptcha API also prohibits
127.0.0.1 as supplied hostnames.
The simplest way to circumvent these issues is to add a hosts entry. For example:
Place this in
/etc/hosts on Linux,
/private/etc/hosts on Mac OS X, or
C:\Windows\System32\Drivers\etc\hosts on Windows.
You can then access your local server via http://test.mydomain.com, and everything will work as expected.
If you intend to run automated integration tests that access a live server, the simplest approach is to use the following dummy hCaptcha site key that always generates a passcode without asking a question. Those passcodes can only be verified using the dummy secret.
In the future, when the dummy sitekey is set the hCaptcha widget will warn users visually in order to remind you not to use them in production.
The dummy keys provide neither anti-bot protection nor earnings, so please double-check that you use them only in your test environment!
Congrats! By following this guide, you now have a complete and working implementation of hCaptcha. By default, hCaptcha supports multiple widgets per page and automatic localization.