Does a chat widget need cookie consent? What EU regulators actually say
"We do not use cookies" is not an answer: the rule covers localStorage too. But one regulator has addressed chat widgets by name, and its answer turns on a single question: does anything get stored before the visitor opens the chat?
The muro team
muro.chat
- Published
- Reading time
- 10 min

On this page
- The rule: Article 5(3) of the ePrivacy Directive
- It is not about cookies
- The identifier is sent back: that is "access"
- When is consent not needed
- The one text that names chat widgets
- Not needing consent is not the same as not telling people
- How long may it stay
- Two more points from the CNIL chatbot page
- What this means in practice
- Limits of this article
- Sources
A chat widget needs to remember who it is talking to. To keep a conversation alive from one page to the next it stores an identifier in the browser, usually in a cookie or in localStorage. In the EU that act of storing is regulated on its own, before any question of personal data. We read the texts that govern it and put the relevant passages side by side: the ePrivacy Directive, the European Data Protection Board guidelines on its technical scope, the Article 29 Working Party opinion on exemptions, and the French regulator, which is the only one we found that addresses chat widgets by name.
The rule: Article 5(3) of the ePrivacy Directive
“Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.”
Two things follow from the wording. The trigger is "storing of information, or the gaining of access to information already stored" on the device: the word cookie does not appear. And there are exactly two exemptions: storage needed purely to carry a communication, and storage "strictly necessary" for a service "explicitly requested" by the user.
It is not about cookies
“According to Article 5(3) ePD, ‘the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user’ is only allowed on the basis of consent or necessity for specific purposes set out in that Article. As reminded in Recital 24 of the ePD, the goal of that provision is to protect the users’ terminal equipment, as they are part of the private sphere of the users. It results from the wording of the Article, that Article 5(3) ePD does not exclusively apply to cookies, but also to ‘similar technologies’. However, there is currently no comprehensive list of the technical operations covered by Article 5(3) ePD.”
“Storage of information in the sense of Article 5(3) ePD refers to placing information on a physical electronic storage medium that is part of a user or subscriber’s terminal equipment. 36. Typically, information is not stored in the terminal equipment of a user or subscriber through direct access to the memory of the device by another party, but rather by instructing software on the terminal equipment to generate specific information. Storage taking place through such instructions is considered to be initiated directly by the other party. This includes making use of established protocols such as browser cookie storage as well as customized software, regardless of who created or installed the protocols or software on the terminal equipment.”
That is the European Data Protection Board, in Guidelines 2/2023 on the technical scope of Article 5(3), version 2.0, adopted on 7 October 2024. A script that tells the browser to write an identifier is "storage initiated directly by the other party", whichever storage API it uses. The guidelines add that the notion "does not depend on the type of medium" (paragraph 38), and that there is no minimum duration or size.
The French regulator spells out the technologies. Its 2020 guidelines apply to HTTP cookies and "also to other technologies", and it lists them:
“They relate, in particular, to the use of HTTP cookies, through which these read or write actions are most often carried out, but also to other technologies such as 'local shared objects', sometimes called 'Flash cookies', the 'local storage' implemented within the HTML 5 standard, identification by calculating a fingerprint of the terminal or 'fingerprinting', identifiers generated by operating systems (whether advertising-related or not: IDFA, IDFV, Android ID, etc.), hardware identifiers (MAC address, serial number or any other identifier of a device), etc. For the application of these guidelines, the word 'tracker' designates all the mechanisms likely to be covered by Article 82 of the Act.”
So a widget that writes a visitor ID to localStorage is in the same position as one that sets a cookie. "No cookies" on a vendor page tells you which API is used, not whether the rule applies.
The identifier is sent back: that is "access"
Storing is half of it. The other half is reading the stored value and sending it to a server, which is what a chat widget does on every page load to find the conversation again.
“A common tool used by companies is the notion of ’unique identifiers‘ or ’persistent identifiers‘. Such identifiers can be derived from persistent personal data (name and surname, email, phone number, etc.), that is hashed on the user’s device, collected and shared amongst several controllers to uniquely identify a person over different datasets (usage data collected through the use of website or application, customer relation management (CRM) data related to online or offline purchase or subscription, etc.). On websites, the persistent personal data is generally obtained in the context of authentication or the subscription to newsletters. 62. As outlined before, the fact that information is being entered by the user would not preclude the application of Article 5(3) ePD with regards to storage, as this information is stored temporarily on the terminal equipment before being collected. 63. In the context of ‘unique identifier’ collection on websites or mobile applications, the entity collecting is instructing the browser (through the distribution of client-side code) to send that information. As such a ’gaining of access’ is taking place and Article 5(3) ePD applies.”
The same guidelines note that information used "strictly inside the terminal" is not accessed in the sense of the Directive "as long as the information does not leave the device" (paragraph 44). A value that travels to the vendor on each page view is the opposite case.
When is consent not needed
The EDPB guidelines deliberately stop at scope. They say so:
“The aim of these Guidelines is to conduct a technical analysis on the scope of application of Article 5(3) ePD, namely to clarify what is technically covered by the phrase ‘to store information or to gain access to information stored in the terminal equipment of a subscriber or user’. These Guidelines do not address the circumstances under which a processing operation may fall within the exemptions from the consent requirement provided for by the ePD, as these circumstances should be analysed on a case-by-case basis accounting for the relevant member state transposition(s), and guidance issued by national Competent Authorities.”
For the exemption itself, the reference at EU level is still Opinion 04/2012 of the Article 29 Working Party, the predecessor of the EDPB. It reads the "explicitly requested" exemption as a two-part test.
“Similarly, the wording of CRITERION B suggests that the European Legislator intended to ensure that the test for qualifying for such an exemption must remain high. Following a direct reading of the directive, a cookie matching CRITERION B has to pass simultaneously the two following tests: 1) The information society service has been explicitly requested by the user: the user (or subscriber) did a positive action to request a service with a clearly defined perimeter. 2) The cookie is strictly needed to enable the information society service: if cookies are disabled, the service will not work. Furthermore, recital 66 of Directive 2009/136/EC underlines that “Exceptions to the obligation to provide information and offer the right to refuse should be limited to those situations where the technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user.” In other words, there has to be a clear link between the strict necessity of a cookie and the delivery of the service explicitly requested by the user for the exemption to apply.”
It also describes the kind of tracker that passes: one tied to an action of the user.
“The term “user input cookies” can be used as a generic term to describe session cookies that are used to keep track of the user’s input in a series of message exchanges with a service provider in a consistent manner. These would be expected to be first party cookies typically relying on a Session-ID (a random temporary unique number) and expire when the session ends at the latest. First party user input session cookies are typically used to keep track of the user’s input when filling online forms over several pages, or as a shopping cart, to keep track of the items the user has selected by clicking on a button (e.g. “add to my shopping cart”). These cookies are clearly needed to provide an information service explicitly requested by the user. Additionally, they are tied to a user’s action (such as clicking on a button or filling a form). As such these cookies are exempted under CRITERION B.”
The one text that names chat widgets
France transposed Article 5(3) in Article 82 of its Data Protection Act, with the same two exemptions. In February 2021 the CNIL published a page of advice on chatbots. It is, to our knowledge, the only official text that applies the exemption to a chat widget by name, and it is unusually concrete:
“In order to ensure the technical continuity of the chatbot or to keep a history of the conversation across the different pages of the site on which it is present, a cookie is frequently placed and read on the user's terminal. Such an action is governed by Article 82 of the French Data Protection Act, on which the CNIL has published guidelines and recommendations. Two options are open to the chatbot operator: either the operator wishes to be able to place a cookie before the chatbot is activated. In that case it must obtain the user's prior consent, which must be free, specific, informed and unambiguous; or the cookie is placed only when the user activates the chatbot (for example, by clicking on the conversation window displayed beforehand, or by clicking on a button explicitly triggering the opening of the chatbot). It is then 'strictly necessary for the provision of an online communication service at the user's express request' and therefore does not require the user's consent to be obtained. This exemption can be relied on only if the tracker is used solely to provide the chatbot: any other purpose attached to it will require the user's consent.”
Source: CNIL, "Chatbots : les conseils de la CNIL pour respecter les droits des personnes", page dated 19 February 2021, quoted above in our translation. It speaks of a "cookie"; under the CNIL guidelines the same reasoning covers localStorage.
The CNIL general guidelines draw the same line for any tracker used for more than one purpose:
“As a reminder, the consent requirement does not apply to operations whose sole purpose is to enable or facilitate communication by electronic means, or which are strictly necessary for the provision of an online communication service at the express request of users. 47. Trackers fall outside the scope of the consent requirement only if they are used exclusively for one or more purposes that can be linked to the exceptions provided for by Article 82 of the French Data Protection Act. 48. The Commission specifies, in this regard, that the use of one and the same tracker for several purposes, some of which do not fall within these exemptions, requires the prior consent of the persons concerned to be obtained, under the conditions recalled by these guidelines. For example, in the case of a service offered via a platform requiring users to authenticate ('logged-in environment'), the publisher of the service may use a cookie to authenticate users without asking for their consent (because this cookie is strictly necessary for the provision of the online communication service). However, it may use this same cookie for advertising purposes only if those users have actually given prior consent to that specific purpose.”
Not needing consent is not the same as not telling people
“The Commission notes that Article 82 of the French Data Protection Act does not require users to be informed of the existence of read and write operations that are not subject to prior consent. For example, the use by a website of a language-preference cookie storing only a value indicating the user's preferred language is likely to be covered by the exemption and does not constitute processing of personal data subject to the GDPR. However, in order to ensure full transparency about these operations, the Commission recommends that users also be informed of the existence of these trackers and of their purposes by including, for example, a statement about them in the privacy policy.”
And once the identifier is tied to a conversation, the GDPR applies to what is collected with it. Online identifiers are named in Recital 30 as something that "may be used to create profiles of the natural persons and identify them". Two provisions set the bar:
“1. Personal data shall be: [...] (c) adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimisation’);”
“The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons.”
Applied to a chat widget, "by default, only personal data which are necessary" is a concrete question: what does the widget send with that identifier on each page load? The full address of the page, including a query string that may hold a reset token or an email address, is not necessary to answer a chat. We measured what widgets actually send in a separate benchmark.
How long may it stay
“A cookie that is exempted from consent should have a lifespan that is in direct relation to the purpose it is used for, and must be set to expire once it is not needed, taking into account the reasonable expectations of the average user or subscriber. This suggests that cookies that match CRITERION A and B will likely be cookies that are set to expire when the browser session ends or even earlier. However, this is not always the case. For example, in the shopping basket scenario presented in the following section, a merchant could set the cookie either to persist past the end of the browser session or for a couple of hours in the future to take into account the fact that the user may accidentally close his browser and could have a reasonable expectation to recover the contents of his shopping basket when he returns to the merchant’s website in the following minutes. In other cases, the user may explicitly ask the service to remember some information from one session to another, which requires the use of persistent cookies to fulfil that purpose.”
There is no fixed legal lifetime. The Working Party ties the lifespan of an exempt tracker to its purpose. You will often see "13 months" quoted as a legal maximum for cookies; in the CNIL recommendation that figure is a recommended lifetime for consent-exempt audience measurement trackers, with 25 months for the data they collect, and it comes with the condition that the lifetime is not extended on each visit. It is a sensible ceiling to borrow for a chat identifier, not a rule that applies to it.
“With regard, more specifically, to audience measurement trackers exempt from consent as described in Article 5 of the guidelines of 17 September 2020, the Commission also recommends that: users be informed of the use of these trackers, for example via the privacy policy of the site or mobile application; the lifetime of the trackers be limited to a period allowing a meaningful comparison of audiences over time, as is the case with a period of thirteen months, and that it not be automatically extended on new visits; the information collected through these trackers be kept for a maximum period of twenty-five months; the lifetimes and retention periods mentioned above be subject to periodic review.”
Two more points from the CNIL chatbot page
“Data must be kept for the period necessary to achieve the purpose of the processing, as defined by the controller. In other words, a distinction must be made between cases where the data should be erased as soon as the conversation ends (as in the case of a chatbot assisting with a purchase) and cases where the controller may legitimately keep the data for longer (for example for a complaint about a purchased product).”
“Since chatbots often offer a free-text mode, they may come to process sensitive data provided directly by the user, without the controller or processor having anticipated it. In this case, organisations are not required to obtain users' prior consent. They must, however, put in place mechanisms to minimise the risks to the rights and freedoms of individuals: by communicating, before any use of the chatbot, a warning inviting people to refrain from communicating sensitive data; by setting up a purge system, immediate or at least regular, because keeping such sensitive data is not relevant.”
A free-text box will receive things nobody planned for. The CNIL does not ask for consent in that case, but it does ask for a warning before use and a purge, immediate or regular.
What this means in practice
- Find out when your widget first writes to the browser. Open your site in a private window, do not touch the chat, and look at cookies and localStorage. If an identifier is already there, your widget is in the "before activation" case.
- Prefer a mode that waits for the click. If the widget can show its button without storing or sending anything until it is opened, the CNIL reasoning puts it under the exemption, as long as the identifier serves only the chat.
- Otherwise, gate it. Load the widget from your consent manager after acceptance. That costs you the visitors who refuse.
- Keep the identifier single-purpose. The moment it feeds analytics or advertising, the exemption is gone.
- Say it in the privacy policy anyway, with the lifetime, even when consent is not required.
- Check what travels with it. The page address, the IP address and anything your site passes to the widget are personal data once tied to that identifier.
For transparency about our own product: muro stores up to five keys in localStorage and no cookie. By default they are written when the widget initialises, which is the "before activation" case described above. Since October 2026 it has a lazy mode (lazy: true in the init call) in which it only draws its button and reads, writes and sends nothing until the visitor opens the chat, and all keys are erased 13 months after the first one was written.
Limits of this article
- Article 5(3) is a directive. Each Member State transposed it and each national authority has its own guidance. We quote the French regulator because it is the one that addresses chat widgets; other authorities may be stricter or silent.
- The CNIL chatbot page dates from 2021 and is advice, not a decision. We found no sanction that turns on a chat widget.
- The EDPB guidelines cover technical scope only and say nothing about when an exemption applies.
- A reform is pending: Commission proposal COM(2025) 837 would move the rule into the GDPR. It is still a proposal and nothing above has changed.
- This is a reading of public texts by a software company, not legal advice.
Sources
- 1Directive 2002/58/EC (ePrivacy), consolidated text, Article 5(3), EUR-Lex (accessed 2026-10-10)
- 2EDPB, Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive, version 2.0, adopted 7 October 2024 (accessed 2026-10-10)
- 3Article 29 Working Party, Opinion 04/2012 on Cookie Consent Exemption (WP 194) (accessed 2026-10-10)
- 4Loi n° 78-17 du 6 janvier 1978 (French Data Protection Act), Article 82, Legifrance (accessed 2026-10-10)
- 5CNIL, guidelines on cookies and other trackers, deliberation n° 2020-091 of 17 September 2020 (accessed 2026-10-10)
- 6CNIL, recommendation on cookies and other trackers, consolidated version of January 2026 (accessed 2026-10-10)
- 7CNIL, "Chatbots : les conseils de la CNIL pour respecter les droits des personnes", 19 February 2021 (accessed 2026-10-10)
- 8Regulation (EU) 2016/679 (GDPR), Articles 5(1)(c) and 25(2), Recital 30, EUR-Lex (accessed 2026-10-10)
- 9European Commission, proposal COM(2025) 837 (Digital Omnibus) (accessed 2026-10-10)


