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 consent. As of October 2026, Anthropic calls artifacts made in a chat "legacy artifacts" and has added a newer sharing model, so this guide separates the two where it matters.
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 Claude artifacts are and where 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. On Free, Pro and Max plans, a published chat artifact gets a public link under claude.ai that anyone with the link can open. On Team and Enterprise plans, artifacts stay inside the organisation by default, and "Anyone with the link" (for people signed in to Claude) is available only when an Owner turns on External sharing, according to Anthropic's guide to sharing artifacts. Artifacts that connect to your apps or use Claude cannot be shared that way. Hosting stays with Anthropic in every case. 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 in an 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. They are listed in the Claude Code cookie guide, which covers claude.ai, and they belong to Anthropic's cookie policy, not yours.
Artifact storage doesn't change this picture. Anthropic's sharing guide says some artifacts save information that everyone who opens them can see, like items in a shared tracker, alongside personal storage, and that unpublishing permanently deletes both. That storage belongs to the artifact on Anthropic's service, not to a cookie your site sets. The cookie rule targets storage on terminal equipment that you control, so on claude.ai it remains Anthropic's to manage. Do tell people before they type personal data into an artifact that uses shared storage.
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.
Embedding an artifact moves the front door to your domain
Embedding moves the front door to your domain. After you publish a chat artifact, Get embed code generates the code, and the Allowed domains field lists the websites that may display it. That is also the answer to running an artifact on your own domain: claude.ai hosting has no custom domain option, so the routes are the embed code, limited to the domains you allow, or exporting the code. Paste the 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.
Exporting the code removes every restraint
Exporting is copying: open the artifact's code view, copy the file, and put it into a project on your own hosting. That 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, and 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 October 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 any missing consent with it.
How do you keep consent right on an exported artifact?
Treat launch day as the consent 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.
Claude artifacts and cookies: quick answers
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, because 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 exported 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 you can hold the non-essential ones until visitors choose. The Free plan covers up to 5 websites.
