Do you need cookie consent for an Instagram feed on your website?

The rule behind cookie banners

Cookie consent doesn’t come from the GDPR directly. In the EU it comes from Article 5(3) of the ePrivacy Directive, implemented in each member state’s law; in the UK, from regulation 6 of the Privacy and Electronic Communications Regulations (PECR). The core idea is the same in both: storing information on a person’s device, or accessing information already stored there, requires consent, unless an exemption applies.

Two points are easy to miss:

1. It isn’t only about cookies. The ICO calls these “storage and access technologies” and lists cookies, tracking pixels, link decoration and navigational tracking, web storage (such as localStorage), device fingerprinting, and scripts and tags. The ICO’s test is “whether the technology stores or accesses information on a device and the purposes for which it does so.”
2. It isn’t only about personal data. The EDPB’s guidelines say the notion of information covers both non-personal and personal data. The ICO adds that where the information stored or accessed is personal data, the UK GDPR also applies, on top of PECR.

How broadly regulators read it

The EDPB’s Guidelines 2/2023 on the technical scope of Article 5(3), adopted in final form in October 2024, read the rule broadly. Two parts are relevant to embeds:

1. Tracking pixels. The EDPB describes a tracking pixel as a link to a resource, usually an image, whose purpose is to make the browser contact the pixel’s host. It says that delivering such a pixel to the user’s device counts as storage “at the very least through the caching mechanism of the client-side software,” so Article 5(3) can apply “even if this storage is not permanent.”
2. IP-only tracking. Where a provider relies only on the IP address to track a user’s navigation, the EDPB says Article 5(3) “could apply even though the instruction to make the IP available has been made by a different entity than the receiving one.”

Just as important is what the EDPB says next: the guidelines do not analyse the exemptions, and the applicability of Article 5(3) “does not systematically mean that consent needs to be collected.” In each case, you assess whether consent is needed or an exemption applies. In other words, being in scope is the start of the analysis, not the end.

The exemptions

Exemptions are where the practical answers come from, and this is where the EU and the UK now differ.

What regulators say about embedded content

Both the ICO and the CNIL address embedded third-party content directly, and their guidance is the closest thing to an official answer for Instagram embeds:

1. ICO on social media plugins: the ICO’s exceptions page says you must get consent for any use of social plugins, unless they only store or access information on the devices of logged-in members of that platform, and that social tracking technologies always require consent.
2. ICO on embedded videos: configure embeds so they don’t set storage and access technologies when the page loads, tell users that pressing play will trigger them, and use a privacy mode where one is available.
3. ICO on font libraries: external fonts can collect data such as IP addresses; users must be told and given a simple, free way to object. This is a useful reference point because, like an image feed, a font library involves a third-party request without any cookie.
4. CNIL on embedded content: the CNIL’s cookie Q&A (April 2026) says publishers that embed external content, such as videos hosted by third parties, must obtain prior consent before the provider places trackers that require consent. Consent can come from the site’s cookie banner or from a dedicated prompt shown before the content is activated, and refusing third-party cookies must not block access to the publisher’s site.
5. CNIL on social buttons: social network buttons generally let those platforms place or read trackers for purposes such as advertising, so consent is required.

Notice the pattern: the guidance is about what the embedded content stores or reads on the device, and for what purpose. That is why two embeds that both show Instagram posts can land in different places.

Instagram’s native embed

When you use the “Embed” option on an Instagram post, the code you paste contains a blockquote and Instagram’s embed.js script. Meta’s documentation says that when the library loads, “it scans the page for the post HTML and generates the fully rendered post.” In practice, the rendered post is an iframe containing a page from instagram.com. That page runs Instagram’s own scripts inside your site, and whatever it stores or reads on the device is decided by Instagram, not by you. (We describe the mechanics in how to embed a single Instagram post.)

Meta’s embed documentation doesn’t describe cookies. So you can’t read the answer off the documentation; you have to look at what the iframe does in a browser, and that can change whenever Instagram updates its embed. Given the ICO and CNIL guidance on social plugins and embedded content, many site owners treat the native embed like other social media embeds and load it only after consent. That is a cautious, defensible default, but the decision is yours.

The Social Feed widget

Our widget works differently, and the differences are exactly the ones the guidance cares about. Here is what it does on the device, taken from its code:

There is no iframe and no Instagram script on your page. The full request-by-request picture is in Instagram feeds and GDPR.

So, do you need consent for the widget?

We can’t give you a yes or no that holds everywhere, and we’d be suspicious of any provider that did. What we can do is set out the considerations honestly:

1. Arguments that weigh against needing consent: the widget sets no cookies and uses no web storage; it adds no identifiers; the view counter produces only an aggregate daily number used for your plan allowance; and the images are content you chose to display, not tracking. In the UK, an aggregate counter of this kind is the sort of thing the statistical purposes exception is written for, provided you give clear information and a simple way to object.
2. Arguments that weigh toward consent or caution: the browser does contact Meta’s servers, and the EDPB reads Article 5(3) broadly, including pixels (our view counter is technically a pixel request) and, in some cases, IP-based tracking. The ICO treats third-party font requests that collect IP addresses as something to tell users about with a way to object. And the exemptions are interpreted narrowly.

Many organizations end up in one of three places: load the widget directly and describe it in the privacy notice; load it directly where their local regulator’s guidance supports that, but gate it in stricter markets; or simply put it behind consent everywhere, because it is easy to do and removes the question. All three are reasonable starting points for a discussion with your adviser. The rest of this article shows how to do the third.

Option 1: let your consent tool hold back the script

Most consent management platforms (CMPs) can block a script until the visitor accepts a category. A common pattern is to change the script’s type to text/plain and add an attribute that names the category; when consent is given, the CMP turns it back into a running script. The exact attribute names differ between tools, so the snippet below is a shape, not something to copy literally:

<!-- Example only: the attribute names depend on your consent tool -->
<script type="text/plain"
        data-consent-category="marketing"
        src="https://n246.grip.space/api/v1/instagram/widget/YOUR-WIDGET-ID"></script>

1. Check your CMP’s documentation for how it blocks third-party scripts and which attribute it expects.
2. Choose the category that matches how you describe the feed in your notice (often “marketing” or “social media”; some tools have a category for third-party content).
3. Add the feed to your CMP’s list of services, with a short description and a link to Meta’s privacy policy, so the consent dialog explains it.
4. Test both paths: reject, then accept, and confirm the feed appears in the right place after acceptance.

Option 2: a click-to-load placeholder

If you don’t use a CMP, or you prefer a contextual choice (the CNIL mentions a dedicated window before content is activated as an acceptable approach), you can show a short message and a button in place of the feed. Nothing is loaded from us or from Instagram until the visitor clicks:

<div id="ig-feed">
  <p>
    This feed shows our latest Instagram posts. Loading it sends a request
    from your browser to Instagram's image servers and to our widget provider.
    <button type="button" id="ig-feed-load">Show Instagram feed</button>
  </p>
</div>
<script>
  document.getElementById('ig-feed-load').addEventListener('click', function () {
    var box = document.getElementById('ig-feed');
    var s = document.createElement('script');
    s.src = 'https://n246.grip.space/api/v1/instagram/widget/YOUR-WIDGET-ID';
    box.innerHTML = '';
    box.appendChild(s);
  });
</script>

Replace YOUR-WIDGET-ID with the ID from your own embed code (the last part of the src address). When the button is clicked, the code creates the widget script inside the box, and the widget draws the feed right after it, inside that same box. This works because a script added this way is still the “current script” while it runs, which is how the widget finds its place. If your site has a Content Security Policy, inline scripts need to be allowed or moved into a file; see our CSP guide.

This simple version doesn’t remember the choice, so the button appears on every visit. If you want the choice remembered, that memory is itself something you store on the device, which is usually best handled by a proper consent tool.

Test your setup

Whichever option you choose, test the result on the live page, not in an editor preview:

1. Open the page in a private window so no earlier consent is remembered.
2. Open the developer tools, go to the Network tab and reload. Before you accept anything, filter for grip.space and instagram: there should be no requests to either.
3. Reject in your consent dialog (or don’t click the button). Confirm that still nothing loads and that the fallback looks right.
4. Reload, accept, and confirm that the widget script loads, the images arrive and the feed appears in the intended spot.
5. Withdraw consent through your CMP’s settings link and reload. The feed should no longer load.
6. Repeat on a phone. Mobile layouts and consent dialogs often behave differently.

Questions to settle with your adviser

If you are taking this to a data protection adviser, these questions make the conversation short and concrete:

1. Which markets do we serve, and which regulator’s guidance do we follow (EDPB plus a national authority, the ICO, or several)?
2. Do we treat a request that sends an IP address to a third party, without any cookie, as needing consent on our site? Do we treat fonts, maps and other embeds the same way?
3. Does the aggregate view counter fit an exemption in our markets, or do we gate the whole widget?
4. If we load the feed without consent, what is our GDPR lawful basis for the transmission to Meta, and is it documented?
5. Which consent category does the feed belong in, and how do we describe it in the consent dialog and the privacy notice?

Write the answers down, with the date and the guidance you relied on. If the rules or your setup change, you will know what to revisit.

What to show visitors who say no

Refusing shouldn’t leave a broken-looking gap. Good fallbacks:

1. A short line and a plain link to your Instagram profile (“See our latest posts on Instagram”). A link loads nothing until it is clicked.
2. A static image you host yourself, such as a photo from your own library, with the same link.
3. Nothing at all, if the feed was purely decorative. Check that the empty space collapses neatly.

Common mistakes

Frequently asked questions

Does the widget set any cookies at all? No. It doesn’t set cookies or use localStorage or sessionStorage. You can confirm it in your browser’s developer tools under Application (or Storage in Firefox).

Can Instagram’s images carry cookies anyway? The widget doesn’t attach anything to the image requests, and they go to Instagram’s CDN hostnames rather than instagram.com. What a given browser sends with them depends on that browser’s cookie handling. Check the request headers in the Network tab if you need certainty for your audit.

Will gating the widget affect my view count? Yes, in a predictable way: a view is counted only when the widget script actually runs, so visitors who don’t accept aren’t counted. That can help on plans with a monthly view limit.

Is the “Powered by Social Feed” credit a tracking link? The credit (always shown on the Free plan, optional on paid plans) links to our website with campaign parameters (utm_source and utm_medium) in the address, so we can see that a visit came from a widget credit. The parameters are the same for every visitor and contain nothing about the person, and nothing is sent unless the visitor clicks the link. The ICO lists link decoration among the technologies it covers, so mention the credit in your notice if you want to be thorough.

Does this apply to visitors outside Europe? These rules are EU and UK rules. Other places have their own laws. Many sites apply one approach worldwide for simplicity.

Do I still need a privacy notice if I gate the feed? Yes. Consent has to be informed, and transparency is required regardless. See what to write in your privacy policy about Instagram embeds.

Related reading

For the full data flow, read Instagram feeds and GDPR. For script placement on different platforms, see where to place the widget script and our guides for WordPress, Shopify, Wix, Squarespace, Webflow and plain HTML. Want to try it? Create a free account or compare the plans.

Sources

1. EDPB, Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive (page): https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22023-technical-scope-art-53-eprivacy-directive_en
2. EDPB, Guidelines 2/2023, Version 2.0 (PDF): https://edpb.europa.eu/system/files/2024-10/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_v2_en_0.pdf
3. ICO, “What are storage and access technologies?”: https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/what-are-storage-and-access-technologies/
4. ICO, “What are the exceptions?”: https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/what-are-the-exceptions/
5. CNIL, “Questions-réponses sur les lignes directrices modificatives et la recommandation « cookies et autres traceurs »”: https://www.cnil.fr/fr/cookies-et-autres-traceurs/regles/cookies/FAQ
6. Meta for Developers, “Embed an Instagram Post”: https://developers.facebook.com/docs/instagram-platform/oembed