Cookie Notice
Last updated 2026-10-24
memo.link does not use tracking cookies, and there is no cookie banner anywhere in this product. This notice exists to explain why, not to ask you for anything.
Public pages set no cookies at all
When someone opens one of your links, yourname.memo.link/something, no cookie is set, and nothing in their browser reaches another company.
Two things happen behind the page, and they are worth describing exactly rather than glossing.
Before showing where a link goes, we ask Google Safe Browsing whether that destination is known to be dangerous. That question is asked by our servers, not by the visitor's browser, and what we send is the link, never anything about the person opening it. The answer is reused for an hour, so it is a question about a destination rather than a record of a visit.
When somebody taps through to the destination, the page tells us that it happened. This one is sent by the browser, so it is named here rather than left out. It carries the address that was already being visited and nothing else, no identifier, no cookie, nothing about the person, and what it adds to is a number: how many people who reached this address went on. There is no record of an individual visit to add it to, which is why a count is all it can ever produce.
This is why there is no consent dialog: there is nothing to consent to. A cookie banner in front of a page someone reached by scanning a QR code would be an obstacle serving no purpose.
Signing in sets exactly one cookie
| Cookie | Set by | Purpose | Lasts |
|---|---|---|---|
| Supabase auth session | memo.link, the dashboard only, never on your links | Keeps you signed in between clicks | Refreshed as you use it; expires after a period of inactivity, and immediately when you sign out |
It is a strictly necessary cookie: without it you would be signed out on every click. The ePrivacy Directive exempts cookies in that category from the consent requirement, which is why you are not asked.
It is never set on *.memo.link addresses, signing in happens only on the main site.
Two preferences, on the main site only. memolink-theme (light, dark or follow the system) and memolink-accent (a colour), read before the first paint so the page does not flash the wrong colour. They contain nothing but those two words and never leave your browser, the account is the copy that follows you to another device. A preference you set is kept in localStorage; storage of something you asked for is exempt from the consent rules for the same reason the sign-in cookie is. A colour you were merely given at random, before you chose anything, is kept in sessionStorage only, for the visit, and gone when the tab closes, because storage you did not ask for is not exempt, and a banner to ask for it would be a worse answer than not keeping it.
We say this precisely because the consent rules cover storage on your device generally, not cookies specifically, a service can avoid the word "cookie" and still be doing exactly the thing the rules are about. This notice used to say we stored nothing at all in localStorage; measured on 2 September 2026, that was wrong by two keys, and it is corrected here rather than by removing the feature.
Claiming a name sets a cookie, for fifteen minutes at most
| Cookie | Set by | Purpose | Lasts |
|---|---|---|---|
memolink-hold- followed by the name, such as memolink-hold-maria | memo.link, when you claim a name, never on your links, and sent back only to the step that ties that name to your email address | Shows that the browser finishing the sign-up is the one that claimed the name, so nobody else can tie your name to their own address while you are typing yours | Fifteen minutes at most, and deleted as soon as the name is tied to your address |
It is strictly necessary in the same sense as the sign-in cookie: without it, anyone who noticed that a name was being claimed could take it from the person claiming it. Its name carries the name you claimed; its value holds only the moment you claimed it and a signature from our server, never your email address, and no script on the page can read it.
The notice you see on the main site
There is a small notice on the main site saying that memo.link sets cookies only for signing in and claiming a name, and nothing that tracks you, with a link here. It is information, not a request for consent, there is no Accept and no Reject because nothing described on this page needs one, and a consent button for storage that needs none would misstate the legal basis. It does not block the page. Dismissing it is remembered in localStorage as memolink-notice, which is storage you asked for by dismissing it. It does not appear on your pages, which store nothing at all.
The offer to install memo.link as an app
When you are signed in on a phone or a tablet, memo.link offers to put itself on your home screen. Two keys in localStorage remember what you did with that offer: memolink-install if you sent it away, and memolink-installed if your browser told us the install finished. Both exist so the offer stops asking, which is storage you asked for by answering it. Neither says anything about you, and neither leaves your browser.
There is a limit worth stating plainly, because it is why the offer can be dismissed at all. On an iPhone or an iPad, a page open in Safari cannot tell whether memo.link is already on your home screen, the installed app is given its own separate storage, so it cannot leave a note for the browser to find. Sending the offer away is the only way to tell us you already have it.
The anti-bot check on the sign-in form
The sign-in form runs Cloudflare Turnstile, which checks you are a person rather than a script requesting sign-in codes in bulk. It is one of two things anywhere in memo.link that come from another company, the other is the error reporter described below, and both are on memo.link itself. Neither is on your pages.
| What | Where | Why |
|---|---|---|
| Cloudflare Turnstile | The sign-in form on memo.link, nowhere else | Stops automated abuse of the one endpoint that sends email |
It stores nothing on your device. Measured on the live sign-in form on 24 August 2026: no cookies, nothing in local storage, nothing in session storage. This notice used to say it "may store something", which was a guess written before anybody looked.
What it does instead is read a few things about the connection as it happens, your IP address, the technical fingerprint of your browser's secure connection, and your browser's User-Agent string, and send them to Cloudflare to decide whether you are a person. Cloudflare says those signals are used "solely to detect and block bots" and not "to identify, profile or target any individuals". It is not on your pages, so people opening your links never encounter it.
Security measures of this kind fall in the same strictly-necessary category as the sign-in cookie: without them the sign-in form would be usable as a tool for flooding other people's inboxes.
The error reporter on the main site
The dashboard runs Sentry, which sends us a report when something breaks. Like Turnstile it is only on memo.link and never on your pages.
It is worth saying what it is not, because error reporting and analytics are often the same product wearing different names. Sentry here records nothing while the product works. Session recording, the feature that would capture what you see and type, is switched off. Reports carry no IP address, no cookies and no request contents.
How we count link opens without cookies
When a link is opened we add one to a number and record today's date. That is the entire mechanism. We do not know who opened it, and no cookie or identifier is involved, so the count cannot be connected to a person even by us.
Nobody can add tracking to their own page
Some link-in-bio services let you add a Meta pixel or a Google Analytics tag to your page. memo.link does not, on any plan. Pages are generated by us from your content, and there is no place to put a script.