When someone on your team asks "are we GDPR compliant?", they usually mean something legal. But by the time the question reaches a frontend developer, almost all of it has turned into concrete, testable behaviour in the browser: what loads before consent, what the banner offers, what cookies get set, and what headers the server sends. The legal text is the why. Your code is the what.
This post translates the parts of GDPR (and the ePrivacy rules that ride alongside it) that you, the developer, actually control — into checks you can verify and automate. No legal degree required.
The one principle that drives most of the frontend work
Consent must be freely given, specific, informed, and unambiguous, and it must be as easy to refuse as to accept. Almost every concrete frontend requirement falls out of that sentence:
- Nothing non-essential should run before the user has chosen.
- "Reject" must be a first-level action, not buried behind "manage preferences."
- The choice must be recorded and respected on the next page load.
If your banner only offers "Accept," or sets analytics cookies the moment the page loads, you are not GDPR compliant no matter what your cookie policy says. That is the part most cookie scanners miss — they count cookies, they do not test whether refusal works.
Regulation → code: a translation table
| What the regulation says | What it means in the browser | How to check it |
|---|---|---|
| Consent before non-essential processing (GDPR Art. 6 + ePrivacy) | No analytics/marketing scripts or cookies fire before the user chooses | Load the page with a fresh profile; assert zero non-essential cookies/storage before any banner click |
| Consent freely given; refusal as easy as acceptance | A first-level "Reject" exists alongside "Accept" | Drive the banner: confirm a Reject control is present and clickable at the first level |
| Consent is unambiguous (no pre-ticked boxes) | No category toggles default to "on" | Inspect the banner's toggles in their initial state |
| Consent is informed (transparency, Art. 13/14) | The banner links to a readable policy naming purposes and vendors | Check the policy link resolves and the named purposes match the cookies actually set |
| Consent can be withdrawn as easily as given | A persistent way to reopen and change choices | Confirm a "cookie settings" entry point remains after the banner closes |
| Data protection by design (Art. 25) + ePrivacy security | Transport and headers protect the data in transit | Check HSTS, a CSP without unsafe-inline/unsafe-eval, secure + HttpOnly cookies |
| Accessibility of the consent mechanism (EAA / WCAG 2.2) | The banner is operable by keyboard and screen reader | Run an automated a11y pass over the banner: labels, focus order, contrast |
None of the right-hand column needs a lawyer. All of it is testable from a browser.
Why your cookie scanner won't catch most of this
A cookie scanner enumerates trackers. It is good at the first row of that table and blind to the rest. It does not click Reject, so it cannot tell you whether refusal is even possible. It does not inspect headers, so it misses the "by design" security requirements. It does not run an accessibility pass.
We ran five major sites — Amazon, BBC, Stripe, GOV.UK, and Cookiebot's own site — through a battery of tools and consistently found the same thing: a clean cookie report sitting next to real consent, header, and accessibility failures. Both reports were accurate. They were measuring different things. (We wrote up the consent-effectiveness side of this in detail in our piece on why a passing Cookiebot scan can still fail an audit.)
Put the checks in your pipeline
The point of turning regulation into testable behaviour is that you can then run it automatically. The free ComplyTest CLI gives deterministic pass/fail across consent, accessibility, and security rules in one command:
npx complytest scan https://your-site.com
Run it against your own site and read the consent and security sections against the table above. The failures map directly back to the regulation — which is exactly what you want when the next person asks "are we GDPR compliant?" and you need an answer with evidence behind it.
The takeaway
"GDPR compliant" sounds like a legal status. For a frontend developer it is mostly a set of concrete, automatable browser checks: consent before processing, a real first-level Reject, no pre-ticked toggles, secure headers, and an accessible banner. Translate the regulation once, encode the checks, and run them in CI — and the legal question becomes a build status you can point at.