Three technologies people call "cookies"
Ask most people how a website remembers them and they'll say "cookies." In reality there are at least three distinct mechanisms doing that job, and they work differently enough that the distinction matters for privacy, performance, and compliance. Cookies, tracking pixels, and local storage each store or move data in their own way. Here's what separates them.
Cookies: small, and sent with every request
A cookie is a small piece of text, up to about 4KB, that a website stores in your browser and ties to a specific domain. Its defining feature is that the browser sends it back automatically on every request to that domain. Load ten pages and the cookie rides along ten times, without any code asking for it. That makes cookies the natural home for things a server needs to see on each request: a session ID that keeps you logged in, a cart token, a security flag. Cookies can be set by a server (through the Set-Cookie header) or by JavaScript, and they carry an expiry date. Full detail in what cookies are.
Tracking pixels: a request, not a store
A tracking pixel, also called a web beacon, is a tiny (often 1x1 and invisible) image or script embedded in a page or email. It doesn't store anything on your device. Its whole job is to fire a request: when your browser loads the pixel, it makes an HTTP call to a remote server, and that call itself is the data. The request reveals your IP address, browser and device, the page or email it fired from, and the time. That's why pixels are the standard way to measure ad conversions and email opens, an email open is literally the pixel loading. Because a pixel works even when a device stores nothing, it's a way to record an event without setting a cookie first (though the server's response can set one).
Local storage: bigger, and stays on the device
Local storage and its sibling session storage make up the Web Storage API. Both keep key-value data in the browser, with a much larger budget than cookies (typically 5-10MB), and, importantly, the data is not sent automatically with every request. It sits on the device until JavaScript from the same origin reads it. That makes web storage good for caching app state, drafts, or UI preferences without bloating every network call.
The two differ by lifespan. localStorage persists until it's explicitly cleared, so it survives closing and reopening the browser. sessionStorage is wiped when the tab or window closes. For a deeper look at the persist-versus-expire idea, see session vs persistent cookies.
Cookies vs Pixels vs Local Storage
| Aspect | Cookies | Tracking pixels | Local storage |
|---|---|---|---|
| Stores data on device? | Yes (up to ~4KB) | No (fires a request) | Yes (~5-10MB) |
| Sent with every request? | Yes, automatically | N/A (is the request) | No, JS reads it |
| Typical use | Sessions, carts, consent | Conversions, email opens | App state, preferences |
| Expiry | Set by expiry date | None (event only) | Until cleared / tab close |
| Needs consent if non-essential? | Yes | Yes | Yes |
The law doesn't care which technology you used
Article 5(3) of the ePrivacy Directive regulates "the storing of information, or the gaining of access to information already stored" on a user's device. It's deliberately technology-neutral. That means non-essential local storage, pixels that read or write device data, fingerprinting, and cookies all fall under the same consent rule. Swapping cookies for local storage to "avoid the cookie law" doesn't work.
Why the distinction matters for compliance
Two practical consequences follow. First, a cookie banner that only governs cookies is incomplete: if your tags also use pixels and local storage for non-essential purposes, those need to be gated by consent too. Second, an audit that only lists cookies will understate what your site actually does. A proper scan looks at cookies, local storage entries, and the outbound network requests that pixels generate. CookieBeam's scanner captures all three (cookies, scripts, and connections), so what you disclose in your cookie policy matches what your site really runs. See how to audit your cookies to get the full picture.
How they work together
In the wild these rarely appear alone. A tracking pixel fires a request; the server's response drops a cookie carrying an ID; later, JavaScript reads a local storage entry to enrich the event before it's sent. The Meta Pixel and Google's tags all combine these techniques. That's why treating them as separate compliance problems fails: a visitor experiences one tracking system, and your consent gate has to govern the whole thing, not the cookie layer alone. There are also related technologies you'll meet in an audit, IndexedDB (a larger in-browser database), and the ETag and cache-based tricks sometimes used to re-identify users. All of them fall under the same "storage of, or access to, information" test, so none is a loophole.
Which should a developer use?
If you're building, the choice usually settles itself. Data the server needs on every request (a session token, an auth flag) belongs in a cookie, ideally with the HttpOnly and Secure attributes so JavaScript and network snoopers can't read it. Data only the client needs (a draft, a UI preference, cached results) belongs in local storage, which keeps it off every request and out of your headers. Never store secrets or tokens in local storage, since any cross-site scripting flaw can read it. And whichever you reach for, if the purpose is non-essential, gate it behind consent before it runs.