Cookie-free analytics and UK GDPR

This is not legal advice. The Information Commissioner’s Office has guidance on storage and access technologies that was updated in 2026 after changes to PECR, and it can move again. Confirm the current guidance, and take advice if your setup is not simple. I will not endorse a particular analytics product as automatically lawful.

I run a small, cookie-free counter called quietstats on leej.uk, and I describe it in the privacy policy. What follows is the map I use to think about that choice, and the limits of what it settles.

Two laws often get mixed up: UK GDPR and PECR

It helps to keep the jobs of the two laws separate, then put them back together.

PECR (the Privacy and Electronic Communications Regulations) includes the UK’s rules on storing or accessing information on a person’s device — cookies, and similar technologies. The ICO’s current guidance treats this as a rule about access to the device, not only about files literally named cookies. Local storage, some kinds of pixel or identifier, and other storage or access techniques can sit in the same regime. The basic PECR pattern, for years, has been: tell people, explain the purpose, and get consent, unless an exception applies. The ICO’s PECR pages and the newer storage-and-access guidance are the primary sources.

UK GDPR is about personal data: information that relates to an identified or identifiable person. An IP address, an online identifier, or a combination of facts that can single someone out can be personal data. If you process personal data, you need a lawful basis, a purpose, a retention period, security, and a notice, among other duties. The ICO’s UK GDPR guidance is the starting point.

The ICO’s current guidance is explicit that you consider PECR first when you are storing or accessing information on a device, and that UK GDPR still applies to any personal-data processing around that. A script can therefore fail for two independent reasons: it writes a cookie without a PECR exception or consent, or it processes personal data without a UK GDPR basis and a decent notice, even if it writes no cookie at all.

That is why “we don’t use cookies” is not a complete answer. It might be a complete answer to one PECR question, if it is true and if no similar technology is in play. It is never, on its own, the end of the UK GDPR question.

What a cookie banner is for, and when it is needed

A cookie banner, at its best, is a way of giving people clear information and a genuine choice before you store or access information on their device in a way that needs consent. At its worst, it is a wall of pre-ticked boxes that hid the “reject” control, which the ICO has been clear is not valid consent.

You do not automatically need a banner because you have a website. You may need a PECR-compliant consent mechanism if you store or access information on the device and no exception applies. You may not need one if you store nothing, or if what you store falls within a current exception (for example, a strictly necessary use, or another exception the ICO currently describes, such as certain statistical purposes, each with conditions). Those exceptions are detailed and conditional. I will not compress them into a slogan. Read the current chapter on exceptions.

In particular, as of the ICO’s 2026 guidance, there is a statistical purposes exception that can apply to some analytics, including some third-party analytics, but only if the conditions are actually met: the sole purpose is statistical information about how the service or site is used, in order to improve it; the information is not used to identify, track or profile people for other purposes; people are told, clearly; they have a simple, free way to object; and a third party, if any, only uses the information to help you improve your service. That is a high bar, and it is one you have to apply to your facts, not to a product’s marketing page.

A banner is also a poor place to hide the rest of a privacy notice. The banner (if you have one) should deal with the storage-and-access choice. The privacy policy should still describe the processing, including analytics, in sentences a person can find later.

What ‘cookie-free’ has to mean in practice

If you want to describe a setup as cookie-free, the claim should survive a look at the network panel and the storage panel, not only a look at document.cookie.

Check, at least:

• Cookies, including those set by a third-party script, a CDN, a chat widget, an embedded video, a payment button, or a font service. The Set-Cookie Analyser will decode a Set-Cookie header you have captured; it will not, on its own, invent a legal basis.
• Local storage, session storage and IndexedDB. A theme preference, a “seen this modal” flag, or an analytics id in local storage is still storage on the device. This site, for example, stores a theme choice as leej-theme when you use the pull cord, and the privacy policy says so. Whether a given item needs consent is a PECR question; pretending it is not storage is not.
• Fingerprinting that tries to recognise a device again without writing a file: a combination of IP address, user-agent, screen size, fonts, canvas, and so on, kept as a lasting identifier. Calling that “cookie-free” is, at best, incomplete, and it can be more intrusive than a first-party cookie with a short life.
• Third-party scripts that you have not actually audited. “Our analytics vendor says they are cookie-free” is a starting claim, not an audit.

Cookie-free, if you use the phrase, should mean: we do not store or access information on your device for analytics, and we have checked. If you store something else, for another purpose, say that separately and apply the current PECR tests to it.

IP addresses, identifiers and ‘do not track’

An analytics system that writes no cookie can still process personal data. IP addresses are the usual example. The ICO has long treated IP addresses as information that can be personal data. What you do with the address matters: holding it, logging it, sharing it, or using it only in memory to produce a daily, salted hash that you cannot reverse, are different designs. I describe the last of those for this site in the privacy policy; I am not holding it out as a design that is automatically lawful for everyone.

Other identifiers — a user-agent string, a coarse location from the edge network, an account id if the person is signed in — can be personal data on their own or in combination. Aggregation (counts of page views) is often the point of analytics, but UK GDPR still applies before the figures are aggregated if you handled personal data to get there.

Two browser signals are worth honouring if you claim to be careful:

• Do Not Track (the DNT request header), and
• Global Privacy Control (usually a Sec-GPC header),

are not, by themselves, a complete legal regime in the UK. They are a clear preference. If a person has gone to the trouble of sending them, a small UK site that does not need to recognise them for advertising has little excuse to ignore them. Quietstats on this site respects both. If you use a vendor, read whether they do, in fact, not in the sales deck.

Don’t log identifiers “just in case.” Retention is part of UK GDPR, and it is also how a cautious analytics design stays cautious.

A cautious setup for a small UK site

For a small content site, a cautious pattern looks like this. It is a starting point for a conversation with current guidance, not a certified architecture.

1. Decide whether you need analytics at all. A site you run for yourself, with a contact form and a handful of articles, may not need more than a count of hits. If you never look at the numbers, don’t collect them.
2. If you do, prefer a first-party, narrow counter: page path, a day, a coarse country if you need it, no advertising, no cross-site id, no sale of data, no attempt to recognise a person across days if you can avoid it.
3. Store nothing on the device for the analytics. Do the work on the server. Don’t write a cookie, a local-storage id, or a sneaky cache trick to re-identify a visitor.
4. Minimise what the server keeps. If you need to avoid counting the same burst of requests twice, prefer a short-lived, in-memory process over a stored IP log. If you keep logs for security, keep them apart from analytics and give them their own retention.
5. Honour DNT and GPC, and provide a simple, published way to object if you are relying on a statistical exception or on any processing a person might reasonably want to opt out of.
6. Don’t add a third-party marketing, chat or video script that quietly reintroduces cookies, then congratulate yourself on the analytics.
7. Look at your headers. A sensible Set-Cookie policy starts with “we don’t set one.” The Security Headers Generator is for the rest of the baseline (HTTPS, referrer policy, and so on); it is not an analytics opinion.

This is close to how I run this site. I am still the person who has to keep the description in /privacy accurate when the software changes, the same habit as maintaining an app after launch.

I will not tell you that Google Analytics, or any named vendor, is automatically fine without a banner, or automatically unlawful. A typical analytics product may set cookies, may use unique identifiers, and may use data for its own purposes. If it does, you apply PECR and UK GDPR to those facts. Some vendors offer a cookieless or EU-oriented mode; those modes still have to be checked, not believed.

What to write in the privacy policy

Whatever you run, write it down in the public notice, in British English, with no leftover template clauses. A useful analytics paragraph says:

• the name of the tool, and that you run it (or that a named vendor does)
• what it is for (“to see which pages are used, so I can improve the site”)
• what is and is not stored on the device
• what the server does with IP addresses and other request data, and for how long
• whether any other company receives the information, and whether they may use it for their own purposes
• how to object, including any browser signals you honour
• a link to a fuller vendor notice, if a vendor is involved

Keep the paragraph short enough to read. The Word Counter is only there if you want a length check; clarity matters more than a word target. If you also have an app, keep this site’s analytics description consistent with the app privacy policy and with any App Store declarations.

Don’t say “anonymous” if you mean “we have not tried very hard to identify you.” Don’t say “we never collect personal data” if you handle IP addresses. Don’t say “no cookies anywhere on this site” if a third-party embed sets one, or if you use local storage for something else without mentioning it.

When a banner is still the honest choice

A banner, done properly, is still the honest choice when:

• you set non-essential cookies, or use a similar technology, and you cannot meet a current PECR exception
• a vendor you want to use will set its own storage, or will use the data for its own purposes
• you want advertising, remarketing, or cross-site measurement
• you are not actually sure what the scripts on the page do, and you have not finished the audit

In those cases, a “we are cookie-free” claim is the problem, not the banner. Build a consent mechanism that works: nothing that needs consent runs before a choice, reject is as easy as accept, the choice is recorded in a way the current guidance allows, and you can change your mind later. Don’t copy a banner from another site and assume its defaults are lawful.

If the only reason you want a banner is that “every site has one,” and your site stores nothing for analytics and meets the current tests for anything else it stores, you may be adding theatre. Theatre is not compliance, and it trains people to click accept without reading. Check, then do the smaller thing if the smaller thing is true.

This is a map, not a sign-off

I have described a cautious shape, the two laws that sit over it, and the way I run one small UK site. I have not:

• certified quietstats, or any other product, as lawful for your use
• told you that the statistical-purposes exception applies to you
• told you that a theme switch in local storage is, or is not, strictly necessary
• given you a banner you can paste, or a promise that you do not need one

Your facts, your scripts, and the current ICO guidance are the inputs. A solicitor or a specialist can give advice; this article cannot. Re-read the guidance when you add a script, not only when you first launch, and update the privacy notice in the same change.

Key takeaways

• PECR is about storing or accessing information on a device; UK GDPR is about personal data. You often have to think about both. This is not legal advice.
• “Cookie-free” has to survive an audit of cookies, local storage and fingerprinting, not just a slogan.
• A banner is for a genuine PECR consent choice when no exception applies; it is not a substitute for a privacy notice, and it is not always required.
• A cautious small-site setup counts minimally, stores nothing on the device for analytics, minimises IP handling, honours DNT and GPC, and names the practice in the policy.
• Don’t treat any named analytics product as automatically lawful, and don’t ignore the ICO’s current exceptions and conditions.

If you want a second pair of eyes on how clearly a site describes its analytics, tell me about it. For a legal view of your own setup, use the ICO’s guidance and a qualified adviser.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.