Client-side rendering

First, you must include the Procaptcha JavaScript resource somewhere in your HTML page. The <script> must be loaded via HTTPS and can be placed anywhere on the page. Inside the <head> tag or immediately after the .procaptcha container are both fine.

<script type="module" src="https://js.prosopo.io/js/procaptcha.bundle.js" async defer></script>

Now, you can either render the Procaptcha widget implicitly or explicitly.

Implicit Rendering

Add an empty DOM container where the Procaptcha widget will be inserted automatically. The container is typically a <div> (but can be any element) and must have class procaptcha and a data-sitekey attribute set to your public site key.

<body>
    <div class="procaptcha" data-sitekey="your_site_key"></div>
</body>

Typically, you’ll want to include the empty .procaptcha container inside an HTML form. When a captcha is successfully solved, a hidden JSON payload 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 procaptcha-response.

Here’s a full example where Procaptcha is being used to protect a signup form from automated abuse. When the form is submitted, the procaptcha-response token will be included with the email and password POST data after the captcha is solved.

Example of implicit rendering

<html>
    <head>
        <title>Procaptcha Demo</title>
        <script type="module" src="https://js.prosopo.io/js/procaptcha.bundle.js" async defer></script>
    </head>
    <body>
        <form action="" method="POST">
            <input type="text" name="email" placeholder="Email" />
            <input type="password" name="password" placeholder="Password" />
            <div class="procaptcha" data-sitekey="your_site_key"></div>
            <br />
            <input type="submit" value="Submit" />
        </form>
    </body>
</html>

Explicit Rendering

If you prefer to render the widget yourself, you can use the Procaptcha.render() method. The Procaptcha.render() must be called after the procaptcha.bundle.js script has loaded.

Example of explicit rendering

The script is loaded in the head of the document and given the id procaptcha-script. A container is created with the id procaptcha-container where the widget will be rendered.

<html>
    <head>
        <script
            type="module"
            id="procaptcha-script"
            src="https://js.prosopo.io/js/procaptcha.bundle.js"
            async
            defer
        ></script>
    </head>
    <body>
        <div id="procaptcha-container"></div>
    </body>
</html>

An onload event is added to the script tag to call the render function when the script has loaded.

// A function that will call the render Procaptcha function when the procaptcha script has loaded
document.getElementById('procaptcha-script').addEventListener('load', function () {
    // Define a callback function to be called when the CAPTCHA is verified
    function onCaptchaVerified(output) {
        console.log('Captcha verified, output: ' + JSON.stringify(output))
    }

    // Get the Element using elementId
    const captchaContainer = document.getElementById('procaptcha-container')
    // Render the CAPTCHA explicitly on a container with id "procaptcha-container"
    window.procaptcha.render(captchaContainer, {
        siteKey: 'YOUR_SITE_KEY',
        theme: 'dark',
        callback: onCaptchaVerified,
    })
})

Procaptcha Options

The Procaptcha.render() function takes an options object as its second argument. The options object can contain the following fields:

Key	Type	Description	Required
siteKey	string	The site key of your application / website. This is required.	✓
callback	string or function	The name of the window function, or a function, that will be called when the CAPTCHA is verified.	✗
theme	string	The theme of the CAPTCHA widget. The default is `light`. The other option is `dark`.	✗
captchaType	string	The type of CAPTCHA to render. The default is `frictionless`. Other options are `image`, `pow`.	✗
chalexpired-callback	string or function	The name of the window function, or a function, that will be called when the CAPTCHA challenge expires.	✗
error-callback	string or function	The name of the window function, or a function, that will be called when an error occurs.	✗
close-callback	string or function	The name of the window function, or a function, that will be called when the CAPTCHA is closed.	✗
open-callback	string or function	The name of the window function, or a function, that will be called when the CAPTCHA is opened.	✗
expired-callback	string or function	The name of the window function, or a function, that will be called when the CAPTCHA solution expires.	✗
failed-callback	string or function	The name of the window function, or a function, that will be called when the CAPTCHA challenge fails.	✗
reset-callback	string or function	The name of the window function, or a function, that will be called when the CAPTCHA is reset.	✗
language	string	The language of the CAPTCHA widget. The default is `en`. All languages can be found here.	✗
sessionId	string	Your own session identifier for this user. Pass the same value to your server-side verification call and the token will only verify if it was earned in that session. See Session correlation.	✗

Data Attributes

The same options can be passed to the implicit rendering method by adding them as data attributes to the .procaptcha container. For example, to set the theme to dark, you would add data-theme="dark" to the .procaptcha container.

<div class="procaptcha" data-sitekey="your_site_key" data-theme="dark"></div>

To set a callback using a data tag, you would add data-callback="yourCallbackFunction" to the .procaptcha container, and define the callback function on the window object.

<div class="procaptcha" data-sitekey="your_site_key" data-callback="yourCallbackFunction"></div>

Session correlation

By default a Procaptcha token proves that somebody solved a captcha for your site. It does not prove that the person submitting the token is the person who solved it. A token solved in one browser can be lifted and posted from another — which is how token-farming and captcha-solving services work.

If your application already has a per-user session identifier, you can close that gap. Render the widget with it, pass the same value to your server-side verification call, and the token will only verify if the two agree.

<div class="procaptcha" data-sitekey="your_site_key" data-sessionid="your_session_id"></div>

Or explicitly:

window.procaptcha.render(captchaContainer, {
    siteKey: 'YOUR_SITE_KEY',
    sessionId: 'your_session_id',
})

The widget attaches the value to the solution when it is submitted. At verification time, a token whose solution carries a different session id — or no session id at all, which is what a token minted outside your session looks like — is rejected with API.CLIENT_SESSION_MISMATCH.

A few things worth knowing:

It is opt-in. Leave it out and nothing changes; no correlation is performed.
It only works if you supply it in both places. Rendering with a session id but omitting it at verification means no check is made, and vice versa.
The value must be one the user cannot choose. The protection comes from your server knowing which session it issued. An id read back from a request the client controls proves nothing.
Use a value that survives the solve. If your session identifier rotates between the widget rendering and the form being submitted, verification will fail for legitimate users.
It is not a secret. It appears in the page HTML, so use a session identifier rather than a session token, and do not put anything in it you would not show the user.
Maximum length is 256 characters. Longer values are dropped by the widget with an error logged to the console.

Prosopo Protect uses this mechanism internally: it renders the challenge widget with its own session JTI, and asserts the same JTI when verifying, so a token solved against one session cannot be replayed against another.

`captchaType`

You can choose to implement any of the following types of captcha when rendering the Procaptcha component:

Type	Description
`frictionless`	The default CAPTCHA type is `frictionless`. This type of CAPTCHA is invisible to the user, only requiring them to complete an invisible Proof of Work challenge (`pow`). Suspected bots are served image captcha challenges (`image`).
`pow`	The `pow` CAPTCHA type requires the user to solve a cryptographic puzzle. This puzzle simply requires a small amount of computational work to solve, and slows down bots significantly, making it difficult for them to scrape in high volumes.
`image`	The `image` CAPTCHA type requires the user to solve a simple image CAPTCHA. This is CAPTCHA type most people are familiar with, created by Google reCAPTCHA.

Please note, if using image or pow, the client side CAPTCHA type must be set to the same value as in the portal:

If your portal CAPTCHA Type is image, you must set the client side CAPTCHA Type to image.
If your portal CAPTCHA Type is pow, you must set the client side CAPTCHA Type to pow.
If your portal CAPTCHA Type is frictionless, you must set the client side CAPTCHA Type to frictionless or leave it blank.

Framework Integrations

Various frameworks have been integrated with Procaptcha. You can find the documentation for each framework below:

Create GitHub Issue

Send us feedback