Technology 3 minutes read

What a consent banner technically does

Between the click on "Reject" and what the browser actually loads afterwards lie several steps. Knowing them makes it quick to tell whether a banner really enforces the decision or merely displays it.

A consent banner is not a sign but a doorkeeper. Its real work is not displaying a question but holding everything else back until the answer arrives. That is precisely where many implementations fail.

The sequence from request to deferred loading

  1. The blocker starts firstA small script at the very top of the document. It intercepts script tags before the browser runs them.
  2. The stored decision is readIf a valid decision exists, no banner appears – and everything permitted starts at once.
  3. The question appearsOnly now, and with nothing requiring consent loading in the meantime.
  4. The answer is stored and loggedLocally for the next visit, on the server for the record: time, banner version, purposes chosen.
  5. Released services start afterwardsOnly the ones agreed to. Refused ones stay put until the decision changes.
Step one is the critical one. If blocking only becomes active after the other scripts, the advertising service has already opened a connection – and the IP address has been transmitted before the question was even visible.

Why the order decides everything

A browser works through a document from top to bottom. If an advertising script tag sits above the blocker, the request has already gone out by the time the blocker starts. It cannot be recalled: the connection was made, the IP address transmitted, a cookie possibly set.

That is why the core of any serious solution is a small script running before everything else. All the rest – design, languages, logging – comes afterwards.

Two builds that look identical from outside

Banner that only displays
Banner that enforces
Scripts keep running regardless of the answer
Scripts start only after release
Refusal merely hides the banner
Refusal prevents the connection
The network log shows external addresses before the click
Before the click only the site's own address appears

What is stored, and where

The decision is stored in two places, each with a different job. In the browser so the question does not reappear on every visit. On the server so it can later be shown that agreement was given – and to what exactly.

The server-side record is not an extra: without it the duty to demonstrate consent cannot be met, because an entry in the data subject's own browser is neither reachable nor tamper-proof.

A sound record holds the time, the purposes presented, the choice made, the version of the texts and the language. What it should not hold is a plaintext IP address: a hash suffices for the record, and a stored address would itself be personal data kept without a ground of its own.

Published 13 August 2026 · last changed 2 September 2026

This article explains general principles and does not replace legal advice on an individual case.

Back to the overview