A Claude artifact published on claude.ai does not need a cookie banner from you, because Anthropic operates the hosting page and the artifact sandbox blocks cookies and browser storage outright. The moment you embed that artifact on your own domain, or export its code and self-host it, cookie consent duties shift to you.
That single distinction - where the artifact runs - decides everything else about compliance.
Published artifacts are hosted on claude.ai, where Anthropic controls the page, its cookies and its consent mechanism.
The artifact sandbox blocks
localStorage,sessionStorageand arbitrary third-party scripts, so a hosted artifact cannot store data on a visitor's device.Embedding an artifact on your site through an iframe makes your domain the entry point, so your cookie policy needs to account for the third-party frame loading from Anthropic's servers.
Exported artifact code running on your own domain is an ordinary website under Article 5(3) of the ePrivacy Directive: analytics, pixels and web storage all need prior consent.
The French CNIL fined SHEIN EUR 150 million in September 2025 for placing cookies before consent - the exact failure an exported artifact plus a pasted analytics snippet recreates by default.
What Are Claude Artifacts and Where Do They Run?
Claude Artifacts are self-contained web pages, documents and small applications that Claude generates inside a chat and renders in a dedicated panel. Each one is a single file running in a locked-down iframe on claude.ai, and that hosting detail matters far more for cookie law than anything in the code itself.
The sandbox is strict. Calls to localStorage or sessionStorage fail, external scripts only load from a short allowlist of approved CDNs, and a Content Security Policy blocks most outbound requests. An artifact cannot drop a _ga cookie or fire a Meta Pixel even if Claude writes the code for it - the browser refuses.
Publishing changes the audience, not the perimeter. A published artifact gets a public link under claude.ai that anyone can open without a Claude account, while artifacts on Team and Enterprise plans can only be shared inside the organisation. Hosting stays with Anthropic either way. Here is how the duties split across the three ways an artifact can reach real visitors:
| Where the artifact runs | Who operates the site | Can it store data on the visitor's device? | Whose consent duties |
|---|---|---|---|
| Draft or published on claude.ai | Anthropic | No - the sandbox blocks cookies and web storage | Anthropic's |
| Embedded on your site via iframe | You (the host page) plus Anthropic (the frame) | The frame stays sandboxed; your page can store freely | Yours for the page and its scripts |
| Exported and self-hosted | You | Yes - no sandbox restrictions remain | Yours entirely |
Do Published Artifacts on Claude.ai Need a Cookie Banner?
No. Visitors to a published artifact land on a page that Anthropic operates, and the ePrivacy Directive, Article 5(3) places the consent duty on whoever stores or reads information on the visitor's device from that page. Inside the sandbox, your artifact can do neither, so there's nothing for a banner of yours to gate.
Anthropic handles its own side. Claude.ai sets authentication, analytics and marketing cookies and offers visitors controls for them - the cookies Anthropic sets on claude.ai are documented separately, and they belong to Anthropic's cookie policy, not yours.
Persistent storage doesn't change this picture. Published artifacts on paid plans can save small amounts of data through a key-value API, but that data lives on Anthropic's servers tied to the artifact, not on the visitor's device, and Anthropic deletes it permanently when the artifact is unpublished. The cookie rule targets storage on terminal equipment, which server-side storage is not.
AI-powered artifacts follow the same logic. When a viewer runs an artifact that calls Claude's API, they sign in and their usage counts against their own account - a relationship between the viewer and Anthropic that your cookie policy plays no part in.
What Happens When You Embed an Artifact on Your Own Site?
Embedding moves the front door to your domain. After publishing, Anthropic's embed feature generates iframe code and asks you to list the allowed domains that may display the artifact. Paste that snippet into your page, and visitors now reach the artifact through a site you operate - which makes your consent setup the one that counts.
The frame itself stays sandboxed, so the artifact still can't write to the visitor's device. Requests to claude.ai to fetch the frame do happen from your page, though, and any storage that results from your page's context is yours to justify. The safe pattern is the one you'd use for any third-party widget: disclose the embed in your cookie policy, and if scanning shows the frame producing storage, gate it behind consent the way you would an embedded video player.
Your own scripts sit outside the sandbox entirely. A host page that runs Google Analytics 4 or a marketing pixel next to the embedded artifact needs the same prior consent as any other page - the GDPR cookie consent requirements attach to the page, not the frame.
Why Does Exporting Artifact Code Change Everything?
Copying an artifact's code to your own hosting removes every technical restraint at once. On Vercel, Netlify or your own server there's no sandbox, no CDN allowlist and no blocked storage API - the app can now do everything the artifact environment forbade, and cookie law applies in full from the first visitor.
This is where the false sense of security bites. The artifact looked cookie-free in Claude because the sandbox forbade tracking; the code was never designed to avoid it. Developers routinely restore localStorage persistence during export and paste in Google Analytics 4 before launch, and both steps trigger consent duties in the EU and UK.
Web storage is not a loophole. The EDPB's Guidelines 2/2023 on the technical scope of Article 5(3), adopted in October 2024, confirm the rule is technology-agnostic: it covers any storage of information on a visitor's device and any access to it, which puts localStorage and sessionStorage squarely in scope alongside cookies, pixels and fingerprinting.
An exported artifact is, legally speaking, just another vibe-coded app. The practical wiring - loading a consent script first, keeping analytics blocked until the visitor chooses - follows the same pattern as adding cookie consent to AI-built apps from Lovable, Bolt or v0.
What Does Enforcement Look Like in Practice?
Regulators sanction the operator of the domain where the storage happens. On 1 September 2025 the French CNIL fined SHEIN's Irish subsidiary EUR 150 million for placing advertising cookies before visitors made any choice, for a banner that hid purposes and third parties, and for continuing to read trackers after people clicked "Reject all".
Two details in that decision matter for artifact builders. Cookie enforcement runs under the ePrivacy Directive rather than the GDPR's one-stop-shop mechanism, so a national regulator can act directly against any site with local visitors, wherever the company sits. And the breach pattern - storage first, consent later, refusal ignored - is precisely what a freshly exported artifact with a pasted analytics snippet and no consent logic produces.
As of August 2026, nothing shields small projects from the same rules. Fine amounts scale with reach, but the consent obligation applies from the first visitor, and a hobby artifact that grows an audience carries its compliance debt with it.
How Do You Keep an Exported Artifact Compliant?
Treat launch day as the compliance boundary. Scan the deployed app with a cookie scanner to see exactly what it stores and loads - the result usually surprises the developer, because build tooling and pasted snippets add storage the original artifact never had.
Categorise what the scan finds, block everything non-essential until the visitor consents, and then test that the banner actually blocks storage rather than just displaying itself. Where you can, keep the artifact's original statelessness: an app that held everything in memory inside the sandbox often doesn't need web storage at all, and the less it stores, the shorter your consent surface.
Frequently Asked Questions
Do I need a cookie banner for a published Claude artifact?
No. Published artifacts are hosted on claude.ai, which Anthropic operates, and the sandbox prevents the artifact from storing anything on a visitor's device. Consent duties there belong to Anthropic, not to the artifact's creator.
Does embedding a Claude artifact add cookies to my website?
The embedded frame stays sandboxed and cannot write to the visitor's device, but it does load from Anthropic's servers. Disclose the embed in your cookie policy and scan the page to confirm what, if anything, results in storage.
Can a Claude artifact use Google Analytics?
Not while it runs on claude.ai - the sandbox blocks tracking scripts. Once the code is exported and self-hosted, Google Analytics can be added, and at that point prior consent is required for its cookies in the EU and UK.
Does localStorage in an exported artifact need consent?
Yes, in most cases. EDPB Guidelines 2/2023 confirm that Article 5(3) of the ePrivacy Directive covers any storage on a visitor's device, so localStorage needs prior consent unless it is strictly necessary for a service the visitor requested.
Whose privacy policy applies to a published Claude artifact?
Anthropic's. Viewers open a page on claude.ai, so Anthropic's privacy policy and cookie controls govern the visit. Your policies only come into play when you embed the artifact on your own site or self-host the exported code.
Scan Your Artifact Before It Ships
If you've exported a Claude artifact to your own domain, find out what it actually stores before your visitors do. Kukie.io scans your site, identifies every cookie and storage item by name and origin, and maps them to the right consent categories - so the app that was clean in the sandbox stays clean in production.
