Indlejret indhold: når YouTube, kort og chat henter data hjem
iframes og widgets forklaret: hvordan en indlejret video, et kort eller en chat-boble skaber en tredjeparts-forbindelse, og hvad reglerne kræver.
Senest opdateret 6. juli 2026
Hvad et indlejret element er, og hvorfor det kontakter en tredjepart, så snart siden loader
Et indlejret element — teknisk set en iframe eller et lille script-drevet widget — er en måde at vise indhold fra en anden hjemmeside direkte inde i din egen side, som var det et lille vindue ind til en fremmed server. Det gælder en video, et kort, en chat-boble eller et bookingmodul: fælles for dem er, at det, der vises, ikke ligger på din egen server, men hentes direkte fra tredjepartens infrastruktur, i det øjeblik siden vises for en besøgende.
Det afgørende er timingen. Browseren kontakter tredjepartens server, så snart elementet skal vises — ikke først, når den besøgende klikker på det, afspiller videoen eller åbner chatten. Forbindelsen til tredjeparten opstår derfor som udgangspunkt ved selve sidevisningen, uanset om den besøgende nogensinde interagerer med det indlejrede element. En besøgende, der aldrig rører ved en indlejret video, har stadig fået sin browser til at kontakte videoudbyderens server, blot ved at siden med videoen blev vist.
Klassiske eksempler: video, kort, chat-widgets og bookingmoduler
Fire typer indlejret indhold går igen på langt de fleste hjemmesider. En indlejret video viser filmklip fra en ekstern videoplatform i stedet for at hoste filen selv. Et kort viser lokation eller rutevejledning via en ekstern korttjeneste. En chat-widget lægger en supportboble ind i hjørnet af siden, leveret og drevet af en ekstern chat-udbyder. Og et bookingmodul indlejrer et eksternt kalender- eller reservationssystem, så den besøgende kan booke tid uden at forlade siden.
Fælles for dem er, at de sparer den, der driver siden, for at bygge funktionaliteten selv — men til gengæld overlader de en del af sidens funktion, og dermed en del af kontakten med de besøgende, til en ekstern leverandør. Chat-widgets og bookingmoduler indsamler derudover ofte oplysninger direkte fra den besøgende, som navn, e-mail eller telefonnummer, i tillæg til de tekniske oplysninger, selve indlæsningen afslører.
Hvordan IP-adresse og cookies deles med tredjeparten — også over grænsen til tredjelande
Når browseren henter et indlejret element, sker det via en almindelig netværksforespørgsel til tredjepartens server — og som ved ethvert andet HTTP-kald følger den besøgendes IP-adresse automatisk med, sammen med tekniske oplysninger om browser og enhed. Det er ikke noget, din side selv sender videre; det er en direkte forbindelse mellem den besøgendes browser og tredjepartens server, som du hverken kan se eller kontrollere indholdet af.
Mange indlejrede elementer sætter derudover deres egen cookie eller en tilsvarende identifikator, på samme måde som et tracking-script kan, jævnfør vores gennemgang af sporingsscripts — det gør det muligt for leverandøren at genkende den samme besøgende igen, hvis vedkommende støder på et element fra samme leverandør på en anden hjemmeside.
Ligger tredjepartens server uden for EU/EØS, er der desuden tale om en overførsel til et tredjeland — et selvstændigt lag af regler oven i selve spørgsmålet om samtykke. Det emne fylder særligt meget, når det indlejrede element kommer fra en amerikansk udbyder, hvilket vi går i dybden med i vores guide om Schrems II og amerikanske tjenester.
Hvad reglerne kræver
Kravet om samtykke, før der sættes eller læses oplysninger via cookies og lignende teknologier, gælder for et indlejret element på samme måde som for et script: det er selve det tidspunkt, hvor elementet begynder at gemme eller læse noget på den besøgendes udstyr, der udløser kravet — ikke et senere tidspunkt, hvor den besøgende måtte vælge at interagere med det. Et bookingmodul eller en chat-widget, der sætter sin egen cookie i det øjeblik siden loader, falder derfor som udgangspunkt ind under samme krav om forudgående samtykke som en tracking-cookie.
Når det indlejrede element også indebærer en overførsel til et tredjeland, kommer databeskyttelsesforordningens kapitel V oven i: der skal foreligge et overførselsgrundlag for selve overførslen, adskilt fra spørgsmålet om samtykke til cookien. Er tredjepartens virksomhed certificeret under EU-U.S. Data Privacy Framework, kan overførslen ske på baggrund af den tilstrækkelighedsafgørelse, der ligger til grund for rammeværket — men kun for de virksomheder, der reelt er på den certificerede liste, hvilket kan tjekkes direkte hos dataprivacyframework.gov.
Datatilsynets vejledning om hjemmesidebesøgende peger desuden på, at den, der integrerer indhold eller plug-ins fra en tredjepart, i nogle tilfælde kan blive fælles dataansvarlig for den indledende indsamling og videregivelse af oplysninger til tredjeparten — en vurdering EU-Domstolen tog stilling til i sagen om et socialt netværks plug-in (sag C-40/17), hvor domstolen fandt, at ansvaret afhang af, om organisationen havde medbestemmelse over formål og hjælpemidler for netop den del af behandlingen. Hvor ansvaret konkret ligger, afhænger af samarbejdet og aftalevilkårene med den enkelte tredjepart, og der findes ifølge vejledningen ingen fast facitliste for rollefordelingen.
Hvor du kan læse de officielle regler
Datatilsynets vejledning om behandling af personoplysninger om hjemmesidebesøgende gennemgår, hvordan indlejret tredjepartsindhold kan udløse fælles dataansvar, med afsæt i EU-Domstolens praksis. Data Privacy Framework-listen gør det muligt at slå en konkret amerikansk leverandør op og se, om den er aktivt certificeret. Databeskyttelsesforordningens kapitel V hos EUR-Lex fastlægger de overordnede regler for overførsel af personoplysninger til tredjelande. Alle tre kilder er samlet herunder, så du kan læse dem i deres fulde ordlyd.