The Site With No Cookies: Do You Still Need a Banner?
A site owner removed every cookie from the site, switched to cookieless analytics, hosted the fonts locally, and asked whether the banner could come down. The site set no cookies. The question sounded reasonable. The answer was no, and the reason was not a cookie. The site still stored a session identifier in localStorage, still sent the visitor's IP address to the analytics provider, and still loaded a script from a third party that set its own storage. The banner was not about cookies. It was about what the site stored and sent, and none of that had gone away.
The cookie is the wrong unit of analysis. The ePrivacy rule that drives the banner does not say cookies. It says storing information on a visitor's device, or gaining access to information already stored there. A cookie is one way to do that. LocalStorage is another. A fingerprint built from the browser and device is another. The question is never whether the site sets a cookie. It is whether the site stores or accesses anything on the visitor's device, and whether it sends personal data to anyone else.
What counts as storage
LocalStorage and sessionStorage are storage, and they are the most common way a cookieless site keeps tracking. A session identifier in localStorage does the same job as a cookie, and the law treats it the same way. So does a fingerprint: a combination of screen size, browser version, installed fonts, and device details that identifies a visitor without storing anything at all. The fingerprint gains access to information on the device, and that access is what the rule covers.
The Kukie guide to consent mode and server-side tagging makes the underlying point: the consent requirement follows the processing, not the mechanism. A site that sends the visitor's IP address and page views to an analytics provider is processing personal data, whether the analytics tool calls itself cookieless or not. The IP address is personal data. The page views are personal data. The tool's marketing does not change that.
What to check before the banner comes down
Audit the site the way a regulator would, not the way the cookie list says. Open the browser storage tab and list everything the site stores: cookies, localStorage, sessionStorage, indexedDB, and cache storage. Then open the network tab and list every request that leaves the site, including the ones to analytics, fonts, maps, and video embeds. The SecurePrivacy audit guide treats this as the basic check: list what the site stores and sends, and compare it with what the banner claims. The gap between the two lists is the audit.
Check the analytics tool's own claims. Cookieless analytics usually means no cookies, not no data. The tool still receives the IP address, the user agent, and the page URL, and it usually stores a hashed identifier to tell repeat visitors apart. That identifier is storage by another name. If the tool's documentation says it stores nothing, read the documentation again, and then check the network tab, because the network tab does not have a marketing department.
When the banner can actually come down
A banner can come down when the site genuinely stores nothing on the visitor's device, accesses nothing already stored there, and sends no personal data to anyone else. That is a real possibility for a small static site with no analytics, no embeds, and no third-party requests. It is not a possibility for a site with analytics, a contact form, a map, a video, or a font loaded from someone else's server. Each of those is a request that carries the visitor's IP address to a third party, and that is enough.
If the banner stays, make it honest about what the site actually does. A banner that says the site uses cookies, on a site that sets none, is a banner that confuses the visitor and misstates the law. Say what the site stores and sends, in plain words, and give the visitor a real choice about it. The banner is not a cookie notice. It is a storage and sharing notice, and it should read like one.
Keep reading: what a small site should keep as consent proof, the third-party requests that load before consent, and the orphaned pages vendors forget cover the nearby cases in this series.
Frequently asked questions
My site sets no cookies. Do I still need a consent banner?
Usually yes. The rule covers storing information on a visitor's device or gaining access to information already stored there, and that includes localStorage, sessionStorage, and fingerprinting. It also covers sending personal data, like an IP address, to a third party. A site with analytics, embeds, or third-party requests still processes personal data even with no cookies.
Is localStorage treated the same as a cookie?
Yes, for consent purposes. A session identifier in localStorage does the same job as a cookie, and the law treats it the same way. The question is whether the site stores or accesses anything on the visitor's device, not what the storage mechanism is called.
What does cookieless analytics actually store?
No cookies, but usually still data. The tool receives the IP address, the user agent, and the page URL, and it usually stores a hashed identifier to tell repeat visitors apart. That identifier is storage by another name. Check the network tab, because it does not have a marketing department.
When can a banner actually come down?
When the site genuinely stores nothing on the visitor's device, accesses nothing already stored there, and sends no personal data to anyone else. That is realistic for a small static site with no analytics, no embeds, and no third-party requests. It is not realistic for a site with analytics, a contact form, a map, or a video.