Privacy Compliance

Hi @asafm7,

Thanks for the detailed suggestion.

In general, hCaptcha is designed as a privacy-first, GDPR-compliant service with minimized data processing and no long-term retention of End User personal data; see hCaptcha’s GDPR overview.

You are right that the current delayed loading mode is based on general page interaction. The plugin also has a developer-level mechanism that can delay loading until a selected element becomes visible, but delaying the hCaptcha API until the user specifically interacts with the protected form is a different feature request.

This sounds reasonable in principle, but implementing it globally is risky because hCaptcha for WP supports many different form integrations. The main issues are:

1. Not every integration uses a normal static element.

Some integrations render forms dynamically, some place the hCaptcha widget outside the actual form, and some use custom JavaScript flows rather than a traditional browser form submission. A simple “listen for focus inside the form” rule would not work reliably everywhere.

2. Submit can be too late as the first interaction.

If the first user action is pressing the submit button, the plugin would need to load the hCaptcha API, render the widget, obtain a token, and then continue the original submission. That is much more complex than simply delaying a script, especially for AJAX-based forms and third-party plugins.

3. Login forms are especially sensitive.

The plugin intentionally avoids delaying some login-related flows for compatibility with password managers, autofill, two-factor/login plugins, and similar behavior. A global form-interaction delay could break those cases.

4. Dynamic forms need extra handling.

Many forms are added or replaced after page load. Supporting this correctly would require observing DOM changes, attaching handlers to newly inserted forms/widgets, and making sure handlers are not duplicated or left behind.

5. The correct trigger is site-specific.

For one site, focusing an input may be the right signal. For another, opening a multi-step form, selecting a payment method, or reaching a checkout step may be the right signal. Choosing one default behavior could easily break existing integrations or create a poor user experience.

Because of these compatibility concerns, I would treat this as a feature request rather than a small change to the existing delay option. If we add this, it would likely need to be opt-in and developer-oriented, so each site can decide exactly when it is safe to load hCaptcha.

We track feature requests on GitHub. Could you please open an issue here with the minimal behavior you need?

It would help if you could include:

• the form/plugin/integration you need this for;
• which exact user action should trigger loading;
• what should happen if the user submits before hCaptcha has finished loading;
• whether a developer hook/filter would be acceptable for your use case.

Because of the compatibility risks above, this would need to be implemented as an opt-in developer hook/filter rather than a global default behavior.

Thanks!

Thanks, that makes sense.

Yes, please open the GitHub feature request and let’s continue the design there. The cascading fallback you describe is exactly the kind of behavior that needs to be discussed and tested outside this support thread, because it can affect many integrations differently.

The existing developer-level mechanism can help only with a narrower case: delaying script loading until a matching element becomes visible. It does not currently delay until submit hover, first field focus/input, or form-specific interaction.

For Jetpack forms, you can experiment with something like this:

add_filter(
	'hcap_delay_api_selector',
	static function () {
		return '.contact-form .h-captcha, .wp-block-jetpack-contact-form .h-captcha';
	}
);

This should delay loading until the hCaptcha widget inside a Jetpack form becomes visible. If the form/widget is already above the fold, it may still load immediately. It also will not implement the interaction-based fallback system you described.

So I’ll close this topic here, and we can continue the feature request on GitHub once opened.

Thanks for testing, and sorry for the confusion.

The filter I mentioned is an existing developer-level mechanism, but it is not the new behavior discussed in the GitHub feature request. It only delays loading until a matching element becomes visible. It does not implement form-specific interaction triggers such as form focus, submit hover/click, or submit interception.

Let’s keep the design and implementation discussion in the GitHub issue, since this requires a new opt-in mechanism rather than troubleshooting the existing visibility-based filter here.

Thank you for your note, I will check it and come back.