Two Different Jobs

When a visitor makes a consent choice, two separate things need to happen. First, the browser has to remember the choice so the banner does not reappear on every page and tags know what they may do. Second, you may need to prove later that the choice was made, what the visitor was shown, and when. These jobs are often handled by different storage mechanisms, and confusing them causes real problems: banners that keep reappearing, choices that vanish on some browsers, or no record to show when someone asks.

This comparison looks at the three common options — first-party cookies, browser storage such as localStorage, and server-side consent records — and where each fits.

Option 1: First-Party Cookies

Cookies are the traditional home for consent state. TCF CMPs commonly store the consent string in a first-party cookie, and many CMPs store their own preference data in one too.

Strengths

• Readable by the server. The cookie is sent with each request, so server-side code, edge logic and server-side tagging can read the choice without waiting for JavaScript.
• Shareable across subdomains. A cookie set on your registrable domain can cover www, blog and shop subdomains.
• Widely expected. Many ad tech integrations look for consent in cookies.

Weaknesses

• Size limits. Browsers cap cookie size at around 4 KB, and a TCF string with many vendors plus other values can approach that.
• Request overhead. Every request to your domain carries the cookie, including image and script requests.
• Lifetime caps in some browsers. Safari’s Intelligent Tracking Prevention limits cookies created through JavaScript to a maximum lifetime of seven days. Cookies set by your own server in an HTTP response are generally treated more generously, though there are exceptions.

Option 2: localStorage and Other Browser Storage

Some CMPs store detailed preferences in localStorage, sometimes alongside a smaller cookie.

Strengths

• More space. Several megabytes per origin, enough for detailed vendor-level choices.
• No request overhead. Nothing is sent to the server automatically.

Weaknesses

• Invisible to the server. Server-side code and edge logic cannot read it, so any server-side decision has to wait for the browser.
• Bound to one origin. Storage on www.example.com is not available on shop.example.com, so a visitor may see the banner again on each subdomain.
• Subject to deletion. Safari can remove script-writable storage, including localStorage, for sites the user has not interacted with for seven days of browser use, and private browsing modes typically clear it when the session ends.

Option 3: Server-Side Consent Records

A server-side record is an entry stored by you or your CMP provider each time a choice is made. It usually contains a pseudonymous identifier, the timestamp, the choices, the banner or policy version shown, and context such as region.

Strengths

• Durable evidence. It survives cookie clearing and browser restrictions, which makes it the right tool for demonstrating that consent was obtained.
• Auditable. You can report on choices over time and answer questions about specific events.
• Cross-device potential. For logged-in readers, a server record can sync choices between devices, if you explain this to them.

Weaknesses

• Not a replacement for local state. Tags in the browser still need a fast, local signal; calling a server on every page view to look up consent adds latency.
• It is personal data itself. Records need a retention period, access controls and a place in your privacy notice.
• Identifier dependency. Anonymous visitors can only be matched to a record through an identifier stored on their device, which brings you back to local storage.

Side-by-Side Summary

• Best for remembering the choice on the web: first-party cookies, ideally set by your server for a stable lifetime.
• Best for detailed preference data in the browser: localStorage, paired with a cookie the server can read.
• Best for proving the choice: server-side records.
• Worst single-option choice: relying only on localStorage, which leaves the server blind and the choice fragile on some browsers.

A Practical Combined Approach

1. Store the authoritative local signal — for example the TCF string and a compact preference record — in a first-party cookie scoped to your registrable domain.
2. Use localStorage only for supplementary data that does not need to reach the server.
3. Write a server-side record for each choice, including the version of the banner and policy shown.
4. If a stored choice disappears, show the banner again rather than assuming a previous answer.
5. Set a re-prompt period for stored choices and record it in your policy.

Storing the visitor’s consent choice itself is generally treated as necessary to deliver the service the visitor asked for — remembering their decision — but check the guidance that applies in your main markets.

Key Takeaways

• Remembering a choice and proving a choice are different jobs needing different storage.
• Cookies are readable by the server and shareable across subdomains but limited in size and, in Safari, lifetime when set by script.
• localStorage offers space but is invisible to the server and can be cleared by browsers.
• Server-side records are the evidence layer, not a substitute for a local signal.
• Combine a server-set first-party cookie, optional browser storage and server records.