Cookyay vs CookieYes — An honest comparison

⚠ Important: if you monetize with Google ads (EEA/UK), Cookyay is not for you

Feature-by-feature comparison

The table below compares Cookyay v11 against CookieYes's free plan and paid plans (Basic / Pro, as of June 2026). CookieYes plan labels vary — "Free" is the no-credit-card tier; paid tiers unlock the features marked below. The most important caveat — the Google-certified CMP / IAB TCF wall — is covered in the section above.

Symbols: ✓ supported  ·  ✗ not supported  ·  ~ partial / conditional

What Cookyay cannot do — deliberate non-goals

Honesty is the point. Here are the things Cookyay deliberately does not do, each with a one-line "why". If any of these are hard requirements for your site, you should use a different tool.

• No Google CMP certification / IAB TCF support (permanent non-goal). See the warning above. Cookyay is not and will not become a Google-certified CMP. IAB TCF registration requires ongoing vendor list management, consent string encoding, and a certification relationship with IAB Europe — the complexity and operating overhead are incompatible with a zero-infrastructure open-source library. Sites serving personalized Google ads to EEA/UK visitors need CookieYes, Cookiebot, or another certified CMP. Why a deliberate non-goal: TCF is designed for adtech platforms, not developer tools; implementing it would balloon the codebase and require ongoing compliance maintenance by a commercial entity.
• No geo-detection (deliberate design choice). Cookyay shows the opt-in consent banner to every visitor, everywhere — including US visitors not subject to GDPR. This is the "strictest everywhere" posture: it eliminates the risk of mis-classifying EU traffic as non-EU (which could expose you to GDPR enforcement), and requires no IP geolocation infrastructure. Why a deliberate non-goal: geo-targeting adds infrastructure dependency and enforcement risk; showing opt-in globally is the correct default for unknown-audience sites.
• No consent analytics, opt-in rate dashboards, or A/B banner testing (permanent non-goal). CookieYes and Cookiebot offer server-side event collection backends that power these features. Cookyay deliberately operates no hosted infrastructure — so there is no backend to collect events from. If you need visibility into opt-in rates, forward cookyay:consent events to your own analytics tool (e.g., Plausible or Fathom). Why a deliberate non-goal: consent analytics require a hosted server — cookyay has no infrastructure to operate and no intent to become a SaaS product.
• No hosted consent log / audit dashboard (permanent non-goal). Cookyay stores consent in the visitor's browser only (cookyay_consent cookie + localStorage). If a regulator asks "show me the consent record for user X on date Y," Cookyay gives you no server-side answer — the data lives only in that user's browser and is inaccessible to you unless you captured it. v10 adds an optional outbound webhook and a programmatic exportConsent() API so you can forward records to your own backend, but the backend is yours to build and host; Cookyay provides no hosted infrastructure. CookieYes (paid) hosts this log for you. Why a deliberate non-goal: no hosted infrastructure is a core design constraint; the webhook + export path gives developers the data they need to build their own.
• No geo-targeted banner variants (see geo-detection above). CookieYes and Cookiebot can show a lighter notice (or no banner) to non-EU/CA visitors. Cookyay cannot. Strictest-everywhere means every visitor sees the opt-in experience.
• No CMS plugins or no-code install (deferred). CookieYes ships WordPress, Shopify, Wix, Squarespace, and GTM integrations for non-technical site owners. Cookyay targets developers who can add a script tag and JSON config. A no-code install path and CMS plugins are deferred — not in scope for v11. Why deferred: the primary audience is developers; non-technical install paths require a separate product investment not yet scoped.
• Framework adapters have known limits (v11). The @cookyay/react adapter targets Next.js App Router only — Pages Router is deferred. The @cookyay/vue adapter has no server-side consent helper (Vue/Nuxt SSR deferred — use getServerConsent from @cookyay/react/server if you need SSR consent reading and are on Next.js). There is no automated CMP config importer — vendor export formats are undocumented and brittle; the migration guide provides per-vendor manual checklists and the scanner is the one automatable step.
• No hosted dashboard. There is no web UI showing consent rates, banner performance, or site analytics. Cookyay ships no infrastructure — you are the operator. Why a deliberate non-goal: a dashboard requires backend infrastructure cookyay deliberately does not operate; use your own analytics tool for banner interaction metrics.
• Runtime auto-block has known coverage gaps and deliberate non-goals (v8). The autoBlock: true flag intercepts known third-party <script>, <iframe>, <img> beacon pixels, fetch/sendBeacon, and XMLHttpRequest calls to curated tracking endpoints. The following remain deliberately out of scope: Pre-consent requests at page unload are dropped, not deferred — a sendBeacon or XHR call fired at pagehide/visibilitychange before the user grants consent is silently dropped; no sessionStorage persistence or cross-session replay (legally correct: no consent = no send). Synchronous XHR (open(..., false)) passes through — holding a sync XHR pre-consent would block the main thread; no curated tracker is sync-XHR-only. Same-origin-iframe XHR is not covered — the window.XMLHttpRequest replacement applies to the top-level browsing context only. Phase-2 async escape window: a few ms while the lazy auto-block chunk loads where an async tracker call can escape — the intrinsic bootstrap-first limit. document.write ad injection — legacy DoubleClick/old AdSense, high page-breakage risk, deferred. Auto-block stays opt-in. Google tags (GTM/GA4) are intentionally not blocked — Consent Mode v2 degrades them gracefully instead.
• Auto-block requires "Cookyay first in <head>". The runtime interception proxy is installed by the synchronous bootstrap snippet. Any <script src> placed in the HTML before the bootstrap cannot be blocked — the browser has already dispatched its fetch before the proxy exists. This is an architectural limit of DOM-level interception. CookieYes can block scripts placed anywhere on the page.
• Limited built-in translations (6 locales in v11; English default). v10 shipped opt-in locale packs for German (de), French (fr), Spanish (es), and Italian (it). v11 adds Arabic (ar) and Hebrew (he) RTL packs. These are tree-shakeable ESM modules — the site owner imports and passes the desired pack; there is no automatic browser-language detection. CookieYes auto-detects browser language and supports 170+ languages without configuration. If your site has visitors in languages outside these six and you cannot supply your own strings config, Cookyay's locale coverage may be insufficient.
• No guarantee of legal compliance. Cookyay implements the technical consent UX patterns described by GDPR, CCPA, and related regulations. Whether your specific deployment is compliant depends on your jurisdiction, your site's data flows, and how you configure the library. This is not legal advice.

Open-source neighbors

Cookyay is not the only open-source option. Two libraries cover significant overlap and are worth knowing:

If you only need banner UI + Consent Mode v2 and don't care about GPC or a local scanner, vanilla-cookieconsent v3 is the more mature choice — it has a larger user base, more themes, and 20+ built-in translations (vs Cookyay's 4-locale v10 packs). Cookyay's differentiators are: the two-part bootstrap (Consent Mode ordering handled automatically), GPC detection, honoring, and persistent indicator (unique among these three as of June 2026), the local CLI scanner (runs against localhost and authenticated pages, with auto-detection of ~60 known third parties and copy-paste blocking snippets), runtime auto-block via autoBlock: true (v8 — intercepts known third-party scripts, iframes, <img> beacon pixels, fetch/sendBeacon, and XMLHttpRequest calls to curated endpoints without HTML changes; same signature database as the scanner; honest about unload-drop behavior, the Phase-2 async escape window, synchronous-XHR pass-through, and same-origin-iframe XHR not covered; document.write still deferred; auto-block opt-in), a maintained, auto-refreshed signature database (v9) with weekly OCD pin-bumps via reviewed PRs and a consumer-readable currency date (SIGNATURES_DATE), v10 EU locale packs (de/fr/es/it, tree-shakeable, default bundle byte-unchanged), v10 consent export API (exportConsent()) and optional outbound webhook, and the strictest-everywhere posture as an explicit design principle rather than an option.

When to switch to Cookyay — and when not to

You can likely drop CookieYes and use Cookyay if:

• You are a developer comfortable editing HTML and running CLI tools.
• You do not serve Google personalized ads to EEA/UK visitors. If your site monetizes with Google AdSense, Ad Manager, or AdMob for EEA/UK visitors, stop here — see the TCF wall above. If you use only Google Analytics, Google Ads conversion tracking, or no Google products at all, Consent Mode v2 (fully supported by Cookyay) is sufficient.
• You want runtime auto-block without HTML changes: enable autoBlock: true (v8) and known third-party scripts, iframes, <img> beacon pixels, fetch/sendBeacon, and XMLHttpRequest calls to curated tracking endpoints are intercepted automatically. The bootstrap snippet must be first in <head> — the same requirement that already exists for Consent Mode v2 ordering. Set debug: true to get a console warning if any known tracker loaded before the bootstrap (v6 install-order diagnostic). Note: pre-consent requests at page unload are dropped, not deferred — this is the legally correct outcome. Synchronous XHR passes through unconditionally (would block the main thread while held).
• You want declarative blocking as well: run the scanner to auto-detect third parties and paste the emitted snippets into your HTML. The scanner covers ~60 known services and produces copy-paste-ready blocking rules — the setup cost is one CLI run + a few HTML edits per site.
• You want the signature database to stay current automatically. Since v9, the OCD source is pinned to a specific commit and a weekly CI job opens a review PR when the upstream moves — no manual refresh step. You can read how current your bundled coverage is via import { SIGNATURES_DATE } from 'cookyay'.
• You want your banner to display in German, French, Spanish, or Italian: v10 ships opt-in locale packs (import de from 'cookyay/locales/de') that cover the priority EU enforcement languages. The locale sets the lang attribute on the Cookyay UI wrapper for correct screen-reader pronunciation (WCAG 3.1.2).
• You want a consent audit trail: use the v10 optional outbound webhook (consent.webhook config) to POST every consent event to your own backend. Or call exportConsent() programmatically to get the full JSON record (including the verbatim shown consent text, for GDPR Art. 7(1) demonstrability). The backend is yours to operate — Cookyay provides the data, not the storage.
• You do not need a hosted consent log — either because your risk profile is low (small site, no DPO) or because you are willing to forward consent events to your own backend via the v10 webhook.
• You want full control over the script that runs on your site (self-hosted, auditable).
• You want GPC to be honored automatically (Cookyay does this; CookieYes does not as of June 2026).
• You need the scanner to run against a local dev server or authenticated pages.
• Cost is a concern (Cookyay is free with no per-domain or per-pageview limits).

You should stay on CookieYes (or a similar SaaS CMP) if:

• You need a server-side consent audit trail. If you are subject to GDPR enforcement risk and need to demonstrate consent records to a regulator on demand, CookieYes's hosted log is the practical solution. Cookyay requires you to build and host this yourself.
• You need geo-targeted banner variants. Cookyay shows the opt-in banner to everyone. If showing a lighter or no banner to US visitors is important to your UX or business (e.g., SaaS with mostly North American traffic), you need geo-detection that Cookyay does not have.
• You need auto-blocking of scripts placed before the consent tool in HTML. Cookyay's runtime interception proxy is installed by the bootstrap snippet — any script that appears in the HTML before the bootstrap cannot be intercepted (the browser has already fetched it). If you cannot guarantee "Cookyay first in <head>" (for example because a CMS injects GTM unconditionally at the top of the page), auto-block cannot help for those scripts. CookieYes does not have this load-order constraint.
• You need IAB TCF compliance or Google CMP certification. See the warning at the top of this page. If you serve Google personalized ads to EEA/UK visitors, Cookyay is not a viable option — this is not a gap to close, it is a permanent architecture decision.
• You need translations beyond the 4 v10 EU locale packs. v10 ships German, French, Spanish, and Italian locale packs. If your site serves visitors in other languages (Portuguese, Dutch, Polish, Swedish, Japanese, etc.) and you cannot supply translated strings via the strings config, Cookyay's locale coverage will not meet your needs. CookieYes auto-detects browser language and supports 170+ languages without any configuration.
• You manage many domains from a single dashboard. Cookyay has no management UI; each domain is an independent deployment.

Ready to switch? Use the migration guide.

The comparison above tells you whether to switch. The migration guide tells you how — with per-vendor checklists covering script removal, category remapping, the scanner step, CSP updates, and the consent-cookie name change that re-prompts returning visitors.

Migration checklists (CookieYes / Cookiebot / OneTrust) →