localStorage og GDPR — kræver det samtykke?

“Det er ikke cookies — det er localStorage. Vi behøver ikke samtykke til det.”

Denne opfattelse er udbredt. Den er også forkert. Og den er dyr at tage fejl af.

Mange webudviklere og marketing-teams tror, at GDPR og cookie-reglerne udelukkende handler om cookies i den tekniske forstand — de HTTP-headerfiler, som browsers gemmer og sender tilbage til servere. localStorage og sessionStorage er anderledes teknologier, og for de fleste lyder det logisk, at de falder uden for reglerne.

Men regulatorer tænker ikke i teknologier. De tænker i formål og konsekvenser.

EDPB (Det Europæiske Databeskyttelsesråd) har i sine retningslinjer 2/2023 om den tekniske rækkevidde af ePrivacy-direktivets artikel 5(3) fastslået det utvetydigt: Samtykkereglen er teknologiagnostisk. Det er ikke lagringsformen, der afgør, om du skal have samtykke — det er hvad du gemmer, og hvad du bruger det til.

Denne artikel giver dig den juridiske og tekniske helhed om localStorage, sessionStorage og GDPR-overholdelse i 2026.

1. localStorage er ikke cookies — men GDPR gælder stadig

Det er rigtigt, at localStorage ikke er cookies i teknisk forstand. Cookies sendes automatisk med HTTP-requests, har udløbsdatoer defineret af serveren, og er designet til server-kommunikation. localStorage er et rent klient-side API, der lever i browseren, aldrig automatisk sendes til servere, og ikke har nogen ind-bygget udløbsdato.

Men “ikke en cookie” er ikke det samme som “uden for GDPR-regulering”.

Der er to overlappende retsgrundlag, der kan kræve samtykke for brug af localStorage:

Epriv acy-direktivet artikel 5(3) — implementeret i dansk ret via cookiebekendtgørelsen — kræver samtykke, før du gemmer eller tilgår information på en brugers terminal-enhed. Ikke cookies. Information. Det er en bevidst teknologiagnostisk formulering.

GDPR artikel 6(1)(a) — kræver samtykke eller et andet gyldigt retsgrundlag for behandling af personoplysninger. Hvis det du gemmer i localStorage er eller kan knyttes til en identificerbar person, er GDPR aktiv.

I praksis aktiverer brugen af localStorage til tracking, analytics eller marketing begge regelsæt samtidigt.

2. Hvad er localStorage og sessionStorage? (teknisk forklaring)

Web Storage API er en browser-standard (defineret i HTML5), der giver websites mulighed for at gemme data direkte i brugerens browser — uden brug af server-kommunikation og uden cookies.

localStorage

localStorage er persistent. Data gemmes uden en udløbsdato og overlever, at browseren lukkes og genåbnes. Data er bundet til et bestemt “origin” (protocol + hostname + port) og kan kun tilgås af scripts fra samme origin.

// Gem data
localStorage.setItem('user_id', 'abc-12345');

// Hent data
const userId = localStorage.getItem('user_id');

// Slet data
localStorage.removeItem('user_id');

En typisk bruger har ingen ide om, at dette sker. Der er ingen synlig indikator i browseren, og data slettes ikke ved lukning af fanen eller browseren.

sessionStorage

sessionStorage fungerer identisk med localStorage i API-forstand, men data er begrænset til ét session. Når brugeren lukker fanen (ikke browseren — fanen), slettes data. Åbner brugeren websitet i en ny fane, starter en ny sessionStorage.

// Gem data for denne session
sessionStorage.setItem('tracking_start', Date.now());

IndexedDB og andre web storage-mekanismer

Web storage-landskabet inkluderer også IndexedDB (en fuldgyldig klient-side database), Cache API (bruges primært af service workers), og WebSQL (forældet). Alle disse teknologier er underlagt de samme principper som localStorage i GDPR-sammenhæng.

Hvad kan gemmes?

I princippet kan alt gemmes som tekst: bruger-ID’er, sessionsidentifikatorer, enhedsfingeraftryk, præferencer, kurv-indhold, A/B-test-varianter, annoncering-IDs, besøgshistorik, og meget mere. Det er de data, der afgør compliance — ikke lagringsteknologien.

3. Forskellen på cookies og web storage

For at forstå compliance er det nyttigt at kende de konkrete tekniske forskelle:

Den vigtigste forskel i compliance-sammenhæng: cookies kan blokeres på server-niveau ved ikke at sætte Set-Cookie headeren. localStorage kræver aktiv blokering af JavaScript-koden, der tilgår localStorage — det sker via korrekt script-blokering i en CMP.

4. GDPR og ePrivacy: Hvornår kræver web storage samtykke?

ePrivacy-direktivets teknologiagnostiske rækkevidde

EDPB udgav i november 2023 retningslinjer 2/2023 om den tekniske rækkevidde af ePrivacy-direktivets artikel 5(3). Den endelige version blev offentliggjort i oktober 2024. Retningslinjerne fastslår fire kriterier, der alle skal være opfyldt, for at samtykkereglen finder anvendelse:

1. Brug af et elektronisk kommunikationsnetværk — websitet skal tilgås via internettet (opfyldt for alle moderne websites)
2. Lagring af information eller tilgang til allerede lagret information — herunder localStorage-operationer
3. På brugerens terminal-enhed — brugerens computer, telefon eller tablet
4. Af en enhed, der er forbundet til det pågældende netværk — websitets server eller tredjepartsscripts

Alle fire kriterier er opfyldt, hver gang et website bruger localStorage.setItem() eller localStorage.getItem(). Det betyder, at den tekniske handling i sig selv udløser ePrivacy-reglerne — uanset om det lagrede indeholder personoplysninger eller ej.

Det er en vigtig pointe: ePrivacy-direktivet beskytter privat sfære og terminal-enhed som sådan. Det er ikke begrænset til personoplysninger i GDPR’s forstand.

Undtagelsen for nødvendige teknologier

Ligesom cookies er der en undtagelse for “teknisk lagring eller adgang, der udelukkende er nødvendig for at muliggøre transmission af en kommunikation” eller for at “levere en tjeneste, som brugeren udtrykkeligt har anmodet om”.

For localStorage betyder det, at du kan anvende det uden samtykke, hvis:

• Du gemmer indhold til en indkøbskurv-session for en butik, brugeren aktivt handler i
• Du gemmer en sessionstoken til autentificering af en logget ind bruger
• Du cacher data for at forhindre tekniske fejl i en tjeneste, brugeren aktivt bruger
• Du gemmer ren applikationstilstand (f.eks. hvilken fane er aktiv), der ikke identificerer brugeren

GDPR ovenpå

Selvom ePrivacy-direktivet dækker selve lagrings- og tilgangshandlingen, dækker GDPR den videre behandling. Hvis de data, du gemmer i localStorage, er personoplysninger eller kan knyttes til identificerbare personer, kræver den videre behandling (analyse, profilering, videregivelse) et selvstændigt retsgrundlag under GDPR.

For tracking og analytics-formål er dette retsgrundlag i praksis altid samtykke — legitim interesse er sjældent tilstrækkelig for denne type behandling.

5. Konkrete eksempler: Hvornår er det okay, hvornår er det ikke?

Eksempel 1 — Indkøbskurv-data (OK uden samtykke)

// Gemmer kurv-indhold til aktiv shopping-session
localStorage.setItem('cart', JSON.stringify(cartItems));

Vurdering: Nødvendigt for den tjeneste, brugeren aktivt efterspørger. Ingen tracking af brugeridentitet på tværs af sessioner. Kræver ikke samtykke.

Eksempel 2 — Google Analytics klient-ID (kræver samtykke)

// Google Analytics gemmer et pseudo-anonymt bruger-ID
localStorage.setItem('_ga', 'GA1.2.1234567890.1234567890');

Vurdering: Dette er et sporing-ID, der identificerer brugeren på tværs af sessioner og muliggør adfærdsanalyse. Det er præcis den type behandling, ePrivacy-direktivet og GDPR kræver samtykke til. Det faktum, at Google Analytics sætter dette i localStorage fremfor en cookie ændrer ikke kravene.

Eksempel 3 — A/B-test variant (grå zone, afhæng af formål)

// Gemmer, hvilken variant brugeren fik tildelt
localStorage.setItem('ab_test_variant', 'B');

Vurdering: Afhænger af, hvad der sker efterfølgende. Hvis varianten udelukkende bruges til at vise en konsistent brugeroplevelse (f.eks. knap A vs. knap B) og ikke sendes til en analytics-server, er det sandsynligvis nødvendigt for den tekniske levering. Hvis varianten rapporteres til et analytics-system og knyttes til brugeradfærd, kræver det samtykke.

Eksempel 4 — Sprogpræference (grå zone)

// Gemmer brugerens foretrukne sprog
localStorage.setItem('lang', 'da');

Vurdering: En ren præference-cookie, der er udtrykkeligt valgt af brugeren, kan argumenteres at være “nødvendig” for at levere den tjeneste, brugeren beder om. Mange tilsynsmyndigheder accepterer dette. Men gemmer du det uden brugerens aktive valg (f.eks. baseret på browser-sprog auto-detect), er argumentet svagere.

Eksempel 5 — Remarketing pixel via localStorage (kræver samtykke)

// Tredjeparts marketing-SDK gemmer tracking-ID
localStorage.setItem('_fbp', 'fb.1.1234567890.123456789');

Vurdering: Marketing og remarketing kræver altid samtykke. Det faktum, at Facebook Pixel eller tilsvarende bruger localStorage fremfor cookies ændrer intet. Mange moderne tracking-scripts bruger bevidst localStorage som fallback, når cookies blokeres — netop for at omgå brugerens valg. Dette er en klar overtrædelse.

Eksempel 6 — Session-tokens for en logget ind bruger (OK uden samtykke)

// Gemmer autentificeringstoken for logget ind bruger
sessionStorage.setItem('session_token', 'eyJhbGc...');

Vurdering: Absolut nødvendigt for at levere den tjeneste (adgangen til konto), som brugeren aktivt har bedt om ved at logge ind. Kræver ikke separat samtykke — men bør nævnes i din cookie-/privatlivspolitik.

6. Teknisk: Sådan blokerer du localStorage korrekt

Det teknisk komplekse ved localStorage er, at det ikke kan blokeres passivt. Cookies kan undlades ved simpelthen ikke at sætte Set-Cookie headeren. localStorage kræver aktiv script-blokering.

Problemet med naiv script-blokering

Den simple løsning — blokér hele <script> tags, der kræver samtykke — er ikke altid tilstrækkelig. Mange tredjeparts-scripts tilgår localStorage som én af mange lagringsmekanismer. Og applikationens egen JavaScript-kode (first-party scripts) kan have localStorage-kald spredt over hele kodebasen.

Løsningsmetode 1 — Script tag blocking (via CMP)

Den mest udbredte metode. CMP’en ændrer type på script-tags fra text/javascript til text/plain, så browseren ikke eksekverer dem. Først når samtykke gives, aktiveres scripts via CMP’ens API.

<!-- Deaktiveret af CMP indtil samtykke -->
<script type="text/plain" data-consent-category="analytics" src="analytics.js"></script>

<!-- CMP aktiverer ved samtykke: -->
<script>
  cmp.onConsent('analytics', function() {
    var script = document.createElement('script');
    script.src = 'analytics.js';
    document.head.appendChild(script);
  });
</script>

Begrænsning: Virker for scripts, der loades som tags. Virker ikke for inline-kode eller first-party kode, der allerede er indlæst.

Løsningsmetode 2 — localStorage proxy/interceptor

En mere robust tilgang er at intercepte selve localStorage API’et. Ved siden-load, inden andre scripts eksekveres, erstattes localStorage med en proxy, der tjekker samtykke-status:

// Intercepter localStorage API - køres som første script på siden
(function() {
  var _originalLocalStorage = window.localStorage;
  var _consentGiven = false;
  var _queue = [];

  Object.defineProperty(window, 'localStorage', {
    get: function() {
      if (_consentGiven) {
        return _originalLocalStorage;
      }
      // Returner et mock-objekt der gemmer i hukommelsen
      return {
        setItem: function(k, v) { _queue.push({k: k, v: v}); },
        getItem: function() { return null; },
        removeItem: function() {},
        clear: function() {}
      };
    }
  });

  window.grantStorageConsent = function() {
    _consentGiven = true;
    // Afspil queued operationer
    _queue.forEach(function(op) {
      _originalLocalStorage.setItem(op.k, op.v);
    });
  };
})();

Note: Dette er et illustrativt eksempel. Produktions-implementeringer kræver mere robusthed og håndtering af edgecases.

Løsningsmetode 3 — Consent-aware first-party kode

For first-party kode er den rene løsning at bygge samtykke-tjek direkte ind:

// Brug kun localStorage til analytics, hvis samtykke er givet
function trackPageView(path) {
  if (!cmp.hasConsent('analytics')) {
    return; // Ingen tracking uden samtykke
  }

  localStorage.setItem('last_page', path);
  analytics.track('page_view', { path: path });
}

Hvad med sessionStorage?

sessionStorage følger nøjagtig samme principper. Det kortere livsforløb (slettes ved fane-lukning) gør det ikke mere undtaget fra reguleringen. Tracking via sessionStorage kræver samtykke på præcis samme vilkår som localStorage.

Tredjeparts scripts og localStorage

Det sværeste problem er tredjeparts scripts, du ikke selv kontrollerer. Mange analytics-, marketing- og support-scripts tilgår localStorage som en del af deres sporingsfunktionalitet — og dokumenterer det ikke altid tydeligt.

Det kræver:

1. En teknisk scanning af dit site, der detekterer faktiske localStorage-operationer
2. Korrekt kategorisering af de scripts, der foretager disse operationer
3. Blokering af de scripts via din CMP, indtil relevant samtykke er givet

7. Privaci.io by bon.do og web storage detection

De fleste cookie-scannere var historisk bygget til at detektere cookies — ikke web storage. Det skaber et blint punkt: dit website kan være fuldt compliant på cookies, mens localStorage-tracking kører uhindret.

Privaci.io by bon.do scanner for og rapporterer:

• Alle localStorage- og sessionStorage-operationer på dit site, inkl. operationer foretaget af tredjeparts scripts
• Kategorisering af web storage-brug — nødvendigt vs. analyse vs. marketing
• Identificering af scripts, der foretager web storage-operationer, så du ved præcis hvilke scripts der skal blokeres
• Detektering af compliance-risici, f.eks. marketing-scripts, der bruger localStorage som cookie-alternativ
• Løbende monitoring, så du opdager nye localStorage-operationer, der introduceres af tredjeparters script-opdateringer

Det er præcis den type detektering, der er nødvendig for at lukke hullet mellem cookie-compliance og den samlede tracking-compliance.

Datatilsynet har for 2026 annonceret tracking på danske websites som et eksplicit tilsynsområde. Det dækker ikke kun cookies — det dækker alle tracking-teknologier, herunder web storage.

Scan dit website for localStorage-brug med Privaci.io

8. FAQ

Er localStorage overhovedet nævnt i GDPR-teksten? Nej. GDPR er teknologiagnostisk og nævner hverken cookies, localStorage eller sessionStorage ved navn. Men GDPR’s krav om retsgrundlag for behandling af personoplysninger gælder uanset lagringsform. Det er ePrivacy-direktivet, der eksplicit adresserer lagring på og adgang til terminal-enheder — ligeledes uden at nævne specifikke teknologier.

Kan jeg argumentere for, at localStorage-data ikke er personoplysninger? Kun hvis det faktisk ikke er muligt at knytte dataene til en identificerbar person — hverken alene eller i kombination med andre data. Et bruger-ID i localStorage er personoplysninger. Et UUID, der sendes til Google Analytics og dér kombineres med brugeradfærd, er personoplysninger. Rene applikationsstate-data (f.eks. “hvilket accordion er åbent”) er formentlig ikke personoplysninger — men er stadig underlagt ePrivacy-direktivets krav om samtykke, da det er lagring på en terminal-enhed.

Hvad med sessionStorage — er det ikke mere privat, fordi det slettes? Det kortere livsforløb ændrer ikke kravene. Selv data, der kun eksisterer i én session, kan bruges til tracking og profilering inden for en session. ePrivacy-direktivets krav gælder lagrings- og tilgangshandlingen som sådan — ikke varigheden af lagringen.

Vores analytics-platform siger, at de er GDPR-compliant. Kan vi stole på det? En platform kan være GDPR-compliant i sin behandling af de data, den modtager — og alligevel kræve, at du indhenter samtykke, inden du lader platformen sætte data på brugerens enhed. Compliance hos din leverandør er ikke det samme som compliance i din integration af leverandøren.

Vi bruger localStorage til performance-caching. Kræver det samtykke? Det afhænger af, hvad der caches. Cacher du generiske ressourcer (CSS, JS-filer, billeder) for at forbedre loading-tid, og ingen brugeridentifikation er involveret, er dette sandsynligvis nødvendig teknisk lagring undtaget fra samtykkekravet. Cacher du brugerspecifikt indhold eller sessionsdata, der kan knyttes til individer, er billedet anderledes.

Hvad med IndexedDB og andre web storage-teknologier? Samme principper gælder. EDPB’s retningslinjer 2/2023 behandler eksplicit, at artikel 5(3) i ePrivacy-direktivet gælder enhver lagrings- og tilgangsoperation på terminal-enheder — uanset teknologi. IndexedDB, Cache API, og Web SQL er alle inden for reguleringsrammen, når de bruges til tracking eller behandling af personoplysninger.

Kan service workers og PWA-caching kræve samtykke? Service workers, der cacher data for at muliggøre offline-funktionalitet i en app, som brugeren aktivt bruger, er sandsynligvis dækket af nødvendighedsundtagelsen. Service workers eller PWA-mekanismer, der bruges til persistering af tracking-data eller brugeridentifikatorer, kræver samtykke.

Hvornår forventer vi en ny ePrivacy-forordning? Europa-Kommissionen trak forslaget til ePrivacy-forordningen tilbage i februar 2025 uden en direkte erstatning. Den eksisterende ePrivacy-direktiv forbliver i kraft. EU’s Digital Omnibus-pakke fra 2025 indeholder begrænsede ændringer, der ville flytte visse terminal-enhed-relaterede krav fra ePrivacy til GDPR (via nye artikler 88a-88b), men dette er fortsat under lovgivningsbehandling. Indtil videre er status quo: ePrivacy-direktivet gælder, og samtykkereglen er teknologiagnostisk.

FAQ

Er localStorage underlagt GDPR og ePrivacy-reglerne?

Ja. ePrivacy-direktivet gælder ikke kun cookies men al lagring af information i brugerens terminal, herunder localStorage, sessionStorage og IndexedDB. Hvis localStorage bruges til sporing eller profilering, kræver det samtykke.

Hvad er forskellen på localStorage og cookies fra et compliance-perspektiv?

Fra et teknisk perspektiv er localStorage og cookies forskellige – localStorage tilgås via JavaScript og sendes ikke automatisk til serveren. Men fra et GDPR-perspektiv behandles de ens: begge kræver samtykke, hvis de bruges til andet end strengt nødvendig funktionalitet.

Kan scannere opdage brug af localStorage til sporing?

De fleste crawler-baserede scannere kan ikke opdage localStorage, da det kræver udførelse af JavaScript i et rigtigt browsermiljø. Privaci kører i et fuldt browsermiljø og kan registrere, hvornår scripts skriver til localStorage under sidens indlæsning.

Hvilke scenarier kræver samtykke for localStorage?

Samtykke er nødvendigt, når localStorage bruges til at gemme unikke bruger-ID’er til sporing, annoncepræferencer, eller data der deles med tredjeparter. Login-tokens og indkøbskurv-data anses typisk som strengt nødvendige og er undtaget.

Hvad bør jeg gøre, hvis jeg opdager uautoriseret brug af localStorage?

Identificér hvilket script der skriver til localStorage, og kontrollér om det sker inden samtykke er givet. Konfigurér din CMP til at blokere det pågældende script, og opdatér din cookiepolitik til at nævne localStorage-brugen.

Er der forskel på, om localStorage bruges af mit eget script eller et tredjeparts script?

Ja, men begge kræver compliance. Dine egne scripts er lettere at kontrollere og blokere via CMP. Tredjeparts scripts er sværere, da de kan opdatere deres adfærd uden din viden – løbende scanning er derfor vigtig.