Why our chat widget sets no cookies, and what that means for your consent banner

If you have ever audited what a third-party chat widget does on your site, you probably closed the tab quickly. Several cookies, often with year-long lifetimes. A tracking pixel. Sometimes a fingerprinting library. A request to a domain you have never heard of. All of it so a support bubble can remember who you are between page loads.

We built Svellyo's widget to do the same job without any of that. This post explains what it stores, why localStorage and not cookies, what still counts as personal data, and how to describe it in your privacy policy so you can stop thinking about it.

What the widget stores in the browser

One thing: a random visitor token, kept in localStorage, scoped to your workspace. It lets the same browser see its previous conversations and receive replies. It is not a tracking identifier. It is not shared between sites, even two sites using Svellyo. It contains no personal data itself.

That is the entire list. No cookies. No pixel. No third-party scripts other than, when realtime is enabled, the websocket library for instant message delivery, which loads from the realtime provider and also sets nothing.

You can see this yourself. Open your site with the widget installed, open developer tools, look at Cookies under Application, and find none from Svellyo. Look at Local Storage and find a single key.

Why localStorage instead of a cookie

Cookies are sent to the server with every request to the domain that set them. That is what makes them a tracking mechanism, and it is why consent law cares about them. A value in localStorage is never sent anywhere automatically. The widget reads it and includes it in its own API calls, and only those.

The practical result is that a cookie banner that lists "functional cookies" has nothing to list for Svellyo. Whether a strictly-necessary functional token needs consent at all varies by jurisdiction and by lawyer, but we chose the mechanism that makes the question smallest.

What is still personal data

Not setting cookies does not mean not processing personal data. Support conversations are personal data by nature. Here is exactly what Svellyo stores when a visitor uses the widget:

• The messages and any attachments in their conversations.
• The page URL and referrer when a conversation started, the browser and operating system family, the approximate country derived from the IP address at that moment, and the widget language.
• Anything your own code passes through identify(): user id, email, name, avatar and attributes.
• A satisfaction rating and comment, if the visitor leaves one.

We do not store the IP address itself beyond deriving a country and a rate-limit hash. We do not fingerprint. We do not build a profile of pages viewed; the widget only knows the page a conversation started on.

Where it lives and who can read it

Data is stored in encrypted Postgres and object storage. Your team reads it through the dashboard, subject to workspace membership checks on every query. Svellyo staff can only access an account through an audited superadmin impersonation that shows a banner to the account and writes a log entry.

AI replies send the visitor's messages and the relevant passages from your knowledge base to the model provider. Nothing else about the visitor is sent, and you can turn the AI off per workspace to send nothing.

The controls you have

Three settings cover most of a data protection officer's questions.

Retention. Under Settings, Retention, pick forever, 90 days or one year. A daily job permanently deletes conversations older than the window, attachments included. Analytics keep only counts.

Export. Any contact can be exported as JSON with their profile, attributes and every message. A whole workspace can be exported too.

Erasure. Deleting a contact removes their identity and attributes and unlinks their conversations. Tick the box to remove the messages as well. This is permanent and takes effect immediately.

Together these let you answer an access request, a portability request or an erasure request in a couple of minutes without contacting us.

What to put in your privacy policy

You do not need a paragraph per vendor, but you do need to name the processor. Something like this is enough:

We use Svellyo (svellyo.com) to provide live chat and support. When you use the chat, your messages, the page you were on, your browser type and approximate country are stored so we can reply to you and improve our help content. If you are signed in, your account email and name are associated with the conversation. The chat widget does not set cookies; it stores a random identifier in your browser's local storage so your conversation continues between pages. Support conversations are kept for [your retention window] and you can ask us to export or delete them at any time.

Replace the bracket with the retention setting you chose. If you use the AI agent, add a sentence that messages may be processed by an AI model provider to generate replies.

For the strictly-necessary argument

Under the ePrivacy rules that most European cookie guidance derives from, storage that is strictly necessary to provide a service the user explicitly requested does not need consent. A visitor who opens a chat and sends a message has requested a service, and remembering that conversation across page loads is necessary to provide it. The token is created at first use of the widget, not on page load, which supports that reading.

We are not your lawyer, and enforcement varies. The point of the design is that the argument is small, the data is minimal, and the mechanism is not one the regulations were written against. If your counsel wants the token created only after the visitor opens the widget, that is already how it works.

What we would not do

We get asked for two features that we have declined so far.

Visitor tracking across pages, so the inbox shows a browsing history next to a chat. It is useful, and it is exactly the thing that turns a support widget into a tracker. The page a conversation started on is enough context for almost every support question.

Cross-site identity, so a visitor identified on one of your products is recognised on another. Tempting for makers with several products, and a privacy problem wearing a convenience hat. Identity stays per workspace. If you want continuity, call identify() on each product with the user's id from your own auth.

The short version

One localStorage token, no cookies, no trackers. Messages, page, browser family, country and whatever you pass through identify. Retention, export and erasure in your hands. One paragraph in your privacy policy. That is the whole surface, and it is small on purpose.