"We don't use cookies, so we don't need a banner" is one of the most common things a site owner tells themselves right before an audit proves them wrong. Sometimes it's true. More often, the site sets cookies it never chose to set, through an embed, a widget, or an analytics snippet installed months ago and forgotten about. And even for the sites that really are cookie-free, the question of whether a banner is required turns out to hinge on something other than the literal presence of a cookie.
Here's how to actually answer the question, instead of guessing from the word "cookie" in your site's name for the feature.
The law doesn't say "cookies"
The EU rule that actually creates the consent requirement, Article 5(3) of the ePrivacy Directive, doesn't use the word cookie at all. It covers "the storage of, or access to, information already stored, in the terminal equipment of a subscriber or user." That's deliberately broad. A traditional HTTP cookie is one way to store information on a visitor's device, but it's not the only one, and it's not what the rule is actually regulating.
Local storage, session storage, browser fingerprinting, device IDs read by an SDK, and tracking pixels that write or read anything on the visitor's side of the connection can all trigger the same obligation a cookie would, even with zero cookies involved. A site that swapped its analytics tool's cookie-based tracking for a fingerprinting-based alternative to sidestep cookie law hasn't sidestepped anything: it's still storing and reading information on the visitor's device, just through a different mechanism.
So the real question isn't "do we set cookies." It's "does anything on this site store or access information on a visitor's device that isn't strictly necessary for the page to function." That's a longer question, but it's the one that actually determines whether you need a banner.
The exemption that actually matters: strictly necessary
Not every cookie, or cookie-equivalent, requires consent. GDPR and the ePrivacy Directive both carve out an exemption for anything "strictly necessary" for a service the visitor explicitly requested: a session cookie that keeps someone logged in, a cart cookie that remembers what they added before checkout, a load-balancing cookie that routes traffic, or a security cookie that helps prevent fraud.
Strictly necessary is a narrow category, not a catch-all. It covers cookies the site cannot function without for the specific thing the visitor is doing right now, not cookies that are merely useful to the business. A cookie that remembers a visitor's login session is strictly necessary. A cookie that remembers their login session and also feeds a marketing attribution model is not, because the marketing use isn't necessary for the login to work.
If everything your site sets falls genuinely into the strictly necessary category, you're in a real, legally recognized exception: you don't need an opt-in consent banner with Accept and Reject buttons, because there's nothing to get consent for. You still need to disclose what you set and why, typically in a cookie policy or the cookie section of your privacy policy, since disclosure and consent are separate obligations. Consent for essential-only cookies can be skipped; a plain statement of what's stored and why generally can't.
Put the two sections above together and the actual decision looks like this:
In practice that split looks like this across four common cookie types:
Audit before you conclude, don't assume
Most sites that believe they're cookie-free have never actually checked. The confident version of "we don't use cookies" usually means "we didn't deliberately add a cookie," which is a different claim from "nothing on this site stores anything on a visitor's device."
A fast way to check: open your site in a fresh private/incognito window, load the homepage, and open your browser's developer tools to the Application (Chrome) or Storage (Firefox) tab. Look at Cookies, Local Storage, and Session Storage for your domain and every third-party domain listed. Anything that shows up there before a visitor has clicked anything is being set without consent, and if it isn't strictly necessary, that's a compliance gap, not a technicality.
The usual sources of cookies a site owner didn't sign up for, in order of how often they get missed:
- Embedded video. A standard YouTube embed sets cookies from google.com and doubleclick.net before playback even starts, tied to ad personalization, not video playback. Google's own privacy-enhanced embed mode (youtube-nocookie.com) reduces but doesn't eliminate this.
- Web fonts loaded from a CDN. Google Fonts served from Google's CDN sends the visitor's IP address to Google on every page load. Self-hosting the font files avoids this entirely, and it's a one-time fix.
- Live chat and support widgets. Nearly all of them set a cookie or local storage entry immediately on load to track the conversation session, whether or not a visitor ever opens the chat window.
- Social share buttons. A native embedded "Like" or "Follow" button, as opposed to a plain link styled to look like one, typically loads a script from the platform that sets its own tracking cookie.
- Analytics installed once and never revisited. Google Analytics, Meta Pixel, and similar tools fire on page load by default unless specifically configured to wait for consent, and configuration drifts as sites get rebuilt or migrated.
Any one of these is enough to move a site out of the cookie-free category, regardless of what the site's own marketing copy claims about itself.
If you actually checked and you're clean
Some sites genuinely are cookie-free: a static brochure site with no analytics, no embeds, no third-party scripts, and no login. If that's an accurate description after checking, not assuming, you don't need a consent banner, because there's no non-essential storage happening for a visitor to consent to.
It's still worth having a short statement to that effect, either as its own short cookie policy or a paragraph inside your privacy policy, saying plainly that the site doesn't use cookies or similar tracking technology beyond what's strictly necessary for it to function. That's not a legal requirement in the way a banner would be, but it closes the question for anyone who checks, and it's one sentence you'll need to revisit and remove the day you add analytics, an embed, or a chat widget, which is the more common outcome than staying cookie-free indefinitely.
Whether your audit turns up nothing or turns up five embeds you forgot about, the disclosure still has to be accurate and specific to what you actually found, not a template that assumes either extreme. Our Cookie Policy Generator builds that disclosure from your actual answers, whether that's a single "we don't use cookies" statement or a full breakdown by category and third-party vendor, and pairs cleanly with a Privacy Policy Generator policy if you're covering both at once. For the wider question of when a banner needs to be opt-in versus opt-out depending on jurisdiction, see our GDPR vs CCPA cookie consent comparison.
The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.