When you create a key in the
reCAPTCHA admin console, you choose its type at creation time:
v2 "I'm not a robot" checkbox,
v2 invisible, or
v3 score-based (with Enterprise
variants layered on top in Google Cloud). That choice
is baked into the key permanently. A v3 key cannot
render a v2 checkbox; a v2 key cannot answer a
grecaptcha.execute() score request. As
Google's
troubleshooting documentation
and the
version reference
spell out, key types are not interchangeable — and
"Invalid key type" is the widget telling you the page
asked the key to be something it is not.
How the Mismatch Actually Happens
The plugin dropdown and the key disagree
The classic case, filling forums from OpenCart to WordPress theme support like LTheme's guide: the plugin's settings page has a version selector — v2 checkbox, v2 invisible, v3 — and the admin selects one version while pasting keys created for another. Tutorials age badly here: a guide written for v2 walks you through creating v2 keys, while your current plugin version defaults to v3. Either selection alone is fine; the combination errors.
Custom code requests the wrong API shape
In hand-rolled integrations the same conflict shows up
in code. A page that loads
api.js and renders
<div class="g-recaptcha"
data-sitekey="..."> is making a v2 checkbox
request. A page that loads
api.js?render=SITE_KEY and calls
grecaptcha.execute() is making a v3
request. Pair either with the other version's key and
the widget refuses. When migrating from v2 to v3,
every load point and execute call must move together —
leftovers from the old integration keep erroring on
pages nobody remembered to update.
Enterprise and classic keys cross paths
Organizations migrating to reCAPTCHA Enterprise (or
being migrated, as classic key management moves into
Google Cloud — see our
pricing and migration guide) add a second axis: Enterprise score keys and
checkbox keys served through
enterprise.js, with their own
CreateAssessment backend. Pasting an
Enterprise key into an integration loading classic
api.js — or vice versa — produces the
same family of key-type errors, which is why Google's
Cloud troubleshooting page lists key/integration
mismatch among its first checks.
The Five-Minute Diagnosis
-
Identify what the page asks for.
View source:
api.js?render=plusgrecaptcha.execute()means v3; ag-recaptchadiv ordata-size="invisible"means v2;enterprise.jsmeans Enterprise. - Identify what the key is. In the admin console, the key's type is shown on its settings page. You cannot change it — only note it.
- Make them match. Either create a new key of the type your code expects, or switch the plugin/code to the version your existing key was created for. Creating the matching key is usually safer than rewriting the integration.
- Update both halves. New site key in the HTML, new secret in the server config — mixed old/new pairs fail verification even after the widget renders.
- Re-test from the failing page in a private window, and confirm the domain list still covers the page's hostname — domain and key-type errors love to travel together, as we cover in the invalid-domain guide.
A Field Guide to the Four Key Types
Keeping the variants straight is half the battle, so here is the cheat sheet worth pinning next to your env files:
-
v2 checkbox — renders the "I'm
not a robot" box; the user may get an image
challenge. Token is produced when the checkbox
completes and is posted with the form as
g-recaptcha-response. -
v2 invisible — same
challenge machinery, no checkbox; the widget is
bound to your submit button and fires on click.
Configured with
data-size="invisible"— and it renders the floating badge, so the branding rules apply. -
v3 score-based — no challenge at
all;
grecaptcha.execute()returns a token whose verification response carries a 0.0 to 1.0 score plus theactionname your code declared. Your server decides what to do with the score; the widget never blocks anyone itself. -
Enterprise — checkbox or
score-based keys managed as Google Cloud
resources, loaded via
enterprise.jsand verified with theCreateAssessmentAPI rather thansiteverify. Classic keys are progressively being pulled into this management plane, which is how formerly stable setups acquire key-type surprises.
Note what stays constant: every variant produces a token in the browser that your server must verify before trusting the request. "Invalid key type" is annoying precisely because it fails earlier than that — the widget will not even render, so no token, no submission, no fallback.
Why a Public Error for a Private Mistake?
Like its sibling "Invalid domain for site key," this banner is addressed to the site owner but performed for the audience. Every minute the mismatch persists, real visitors stare at a red error and a form that will not submit. The configuration surface — four key types, two script URLs, plugin dropdowns, paired secrets — is large enough that mistakes are routine, and the failure mode is a public outage rather than an operator alert.
The defensive habits are the same ones that catch domain drift: record which key type each property uses alongside your environment configs, make version changes a checklist item that touches frontend, backend, and plugin settings together, and run a synthetic check that loads each protected form and asserts the widget rendered. It is also fair to weigh configuration complexity when choosing a verification layer — systems with a single integration mode, such as rCAPTCHA's behavioral verification, leave fewer wires to cross, though every provider's config still belongs under the same monitoring.
People Also Ask: Invalid Key Type FAQ
What does "ERROR for site owner: Invalid key type" mean?
The reCAPTCHA site key on the page was created for a different version of reCAPTCHA than the one the page's code (or plugin setting) is using — for example, a v2 checkbox key with v3 score-based code. The key and the integration version must match.
Can I convert a v2 key to v3?
No. The type is fixed when the key is created. Create a new key of the needed type in the admin console and update both the site key and the secret in your integration.
Do v2 and v3 use the same secret key verification?
Both classic versions verify tokens server-side via
siteverify, but tokens from one version's
widget cannot be verified with another version's
secret. Enterprise keys use the separate
CreateAssessment API instead. Always
replace the key pair together.
Why did this error appear without any changes on my site?
Usually something did change: a plugin update that switched its default reCAPTCHA version, a theme update that altered the integration, or a key migration on the Google Cloud side. Check the plugin's version selector against your key's type first.
Conclusion
"Invalid key type" is a version handshake failing in public. The key knows what it is, the page knows what it wants, and they were configured by different tutorials. Read the page's integration to learn which version it speaks, read the admin console to learn which version the key is, and make them agree — creating a fresh matching key when in doubt. Then write the pairing down where the next admin will find it, because the error you just fixed is one plugin update away from a return visit.