Most sites don't set only strictly necessary cookies, and they don't set only non-essential ones either. They set a mix, a handful of session and security cookies alongside analytics, an A/B testing tool, maybe a chat widget, maybe an ad pixel, and every one of those has to land in the right bucket before a consent banner or a cookie policy can be built correctly. Get the categorization wrong in one direction and you're loading trackers before consent. Get it wrong in the other and you're asking visitors to consent to cookies your site genuinely can't function without.
This is a categorization exercise, not a legal trivia question, and it's worth doing carefully: "strictly necessary" is the one label that lets a cookie skip consent entirely, which makes it the label vendors, marketers, and well-meaning developers reach for whenever they want a cookie to avoid the banner. Here's the actual test regulators apply, and how to run every cookie on your site through it.
The test isn't "important." It's "necessary for what the visitor asked for."
The strictly necessary exemption comes from Article 5(3) of the ePrivacy Directive and its national implementations across the EU and UK, and it's narrower than the plain-English meaning of "necessary" suggests. A cookie qualifies only if it's required to provide a service the visitor has explicitly requested, not a service the business finds useful to run.
That distinction is the whole test. A login session cookie is strictly necessary because the visitor asked to be logged in, and the site cannot keep them logged in without it. A shopping cart cookie is strictly necessary because the visitor asked to add an item to a cart, and the cart cannot remember that item without it. A load balancing cookie that routes a request to the right server, or a security cookie that helps detect a fraudulent login attempt, both qualify because they support the basic technical delivery of a service the visitor is actively using.
An analytics cookie that measures how visitors move through the site does not qualify, no matter how useful the resulting data is to the business, because the visitor didn't ask for their behavior to be measured. The service they requested (viewing the page) works identically whether or not the analytics cookie fires. That's the line: does the cookie serve the request the visitor made, or does it serve a purpose the business has layered on top of that request. Only the first kind is exempt from consent.
That third question, whether the cookie also serves a second purpose, is where a lot of categorization goes wrong. A cookie doesn't stay strictly necessary just because part of what it does is necessary. If a session cookie also feeds a marketing attribution model, or an "essential" analytics tool also reports back to an ad network, the added purpose disqualifies the whole cookie from the exemption, because consent has to cover everything the cookie actually does, not just the part you'd prefer to disclose.
Where the common categories actually land
Most cookie policies group cookies into four categories: strictly necessary, functional, analytics, and marketing (sometimes functional and analytics get merged, or marketing gets split into advertising and personalization, but the four-way split is the most common shape). Only the first is exempt from consent. The other three, regardless of how useful or low-risk they seem, require an opt-in.
Where common cookie types actually land
| Category | Requires consent | |
|---|---|---|
| Session/login authentication | Strictly necessary | |
| Shopping cart contents | Strictly necessary | |
| Load balancing / server routing | Strictly necessary | |
| Security / fraud detection | Strictly necessary | |
| Cookie consent choice itself | Strictly necessary | |
| Language or currency preference | Functional | |
| Remembered form field values | Functional | |
| Site analytics (GA4, Plausible, etc.) | Analytics | |
| A/B testing and personalization | Analytics/functional | |
| Ad targeting and retargeting pixels | Marketing | |
| Social media share/embed cookies | Marketing |
The row worth pausing on is the cookie that stores the visitor's consent choice itself. That one is genuinely strictly necessary: without it, the banner has no way to remember that a visitor already answered, and it would have to ask again on every page. It's a useful example of the test working correctly on an edge case, since the cookie exists purely to support the mechanism the visitor is actively using (the consent banner) rather than any secondary business purpose.
Functional cookies are the category people most often try to smuggle into strictly necessary, and it's worth being direct about why that doesn't work. A remembered language preference makes the site nicer to use, but the site functions, pages load, forms submit, without it. "Nicer" isn't the test. "Cannot function" is.
The three ways categorization actually goes wrong
Treating "we built it for a good reason" as the test. A developer who added an analytics cookie specifically to catch and fix bugs faster, or a support cookie added specifically to reduce ticket volume, often assumes the good internal reason makes the cookie necessary. It doesn't. The test asks what the visitor requested, not what problem the business was trying to solve when it added the cookie.
Letting one necessary purpose cover a bundled tool. This is the most common real-world miscategorization, and the one most likely to actually invalidate a banner if a regulator or a scanning tool catches it. A single script tag from a chat widget, a video embed, or an all-in-one marketing platform frequently sets several cookies at once, one of them genuinely functional, the rest analytics or marketing. Categorizing the whole vendor as strictly necessary because one of its cookies is defensible drags every other cookie it sets out of consent along with it.
Assuming a first-party cookie is automatically safer than a third-party one. First-party versus third-party is a technical distinction about which domain set the cookie. It has no bearing on the strictly necessary test. A first-party analytics cookie your own domain sets directly is exactly as non-essential as a third-party one a vendor's script sets on your behalf, because the question is still what purpose the cookie serves, not who technically wrote it.
Running an actual audit catches all three. Open your site in a fresh, unauthenticated browser session, load the homepage before clicking anything, and check your browser's developer tools under Application (Chrome) or Storage (Firefox) for every cookie already present. Anything set before a visitor has made a choice needs to be strictly necessary to justify being there at all; anything that isn't is a sign the banner is loading a tracker too early, independent of whether the cookie was correctly categorized once someone got around to it.
Writing the category into your policy, specifically
Once a cookie's category is settled, the policy entry needs to say so in a way a visitor (or a regulator) can actually verify, not in the generic language a lot of template policies fall back to.
- This cookie is necessary for the site to work properly.
- We use cookies to improve your experience and for security purposes.
- session_id: strictly necessary, keeps you logged in, no consent required.
- _ga: analytics, measures page views and duration, requires consent, expires in 13 months.
The specific version names the actual cookie, states its category plainly, and gives the reason that category applies, which is what turns "strictly necessary" from an assertion into something a reader can check against the test above. It also happens to be the format a regulator or a cookie-scanning audit tool is looking for when it checks whether a site's stated categories match what the site's cookies actually do.
This distinction between a static disclosure document and the interactive banner that enforces it is worth understanding on its own; our guide on cookie policy vs cookie consent banner covers where each one's obligations start and stop. And if your audit turns up nothing beyond cookies that genuinely are strictly necessary, categorization also answers the separate question of whether you need a banner at all, which our guide on whether you need a cookie banner without cookies walks through for that specific case.
Building the category list without guessing
The categorization work above, cookie by cookie, against the actual necessity test, is the input a cookie policy needs before it can be written accurately. Skipping it and writing generic category descriptions instead is how a policy ends up saying "strictly necessary" over a cookie that, run through the test honestly, plainly isn't.
Our Cookie Policy Generator builds the disclosure from the categories and cookies you specify, so the policy states what each category actually contains rather than falling back to boilerplate language that doesn't hold up against the test a regulator would apply to the same cookie.
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.
