Does a Short Link Click Need Cookie Consent? Law by Law

You shortened a link. Somebody clicked it. Your dashboard says one click from Hamburg, Chrome, Android, arriving from a newsletter. You set no cookie and fired no pixel. Then a subscriber writes to ask whether you had consent for that, and every page you can find answers the question for a website rather than for a redirect.

This is that page. The question is narrow and deserves a narrow answer: when a short-link service performs a 302 redirect and records IP-derived country, device, operating system, browser, the referring page and a timestamp, with no cookie written to the browser, is that a consent event? We work it through against EU ePrivacy Article 5(3) as the EDPB reads it, UK PECR regulation 6 as the ICO now reads it, German TDDDG section 25, French Article 82, Italy's 2026 tracking-pixel guidelines, California's CCPA and CIPA, Brazil's LGPD and India's DPDP Act, verified on 10 September 2026.

Three things happen when someone clicks

Strip the marketing language away and a short link does three things. The client sends an HTTP request, the service answers with a 302 and a Location header, and the client follows it. Along the way the service sees the connection metadata any HTTP server sees and decides what to keep. Click tracking is that last decision and nothing more, which is why the usual cookie-banner analysis does not fit.

Tap to enlarge

Why "is it a cookie" is the wrong test

Most compliance content asks whether you set a cookie, because cookies are what banner vendors sell against. The law asks something else. Article 5(3) covers storing information in, or gaining access to information stored in, the terminal equipment of a subscriber or user, and the EDPB is blunt that the word chosen was not "personal data" but "information". So the test is not "did I write a cookie" but "did anything land on, or get read from, that device because of me". Ask it that way and a redirect stops looking obviously safe.

The single most useful document here is the European Data Protection Board's Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive, version 2.0, adopted on 7 October 2024. It is a technical scoping document, not a consent guide, and its section 3.1 is titled "URL and pixel tracking". Most summaries give tracking links one line and move on.

Tap to enlarge

Paragraph 49: the identifier is appended to the address

The EDPB defines a tracking link by contrast with a pixel: it works the same way, but "the identifier is appended to the website address". When the URL is visited, the target site loads the requested resource "but also collects an identifier which is not relevant in terms of resource identification". The example the Board picks is affiliate marketing, so if you run affiliate links, that paragraph is about you.

Paragraphs 50 and 51: distribution is storage, collection is access

This is the part that surprises people. Tracking links can be distributed "through emails, web sites, or even, in the case of tracking links, through any kind of text messaging systems", and that distribution "does constitute storage, at the very least through the caching mechanism of the client-side software. As such, Article 5(3) ePD is applicable, even if this storage is not permanent." Paragraph 51 closes the loop: adding tracking information to a URL instructs the terminal equipment to send the identifier back, so collecting it "constitutes a gaining of access". Two independent hooks, one link. Put tracked links in SMS campaigns or newsletters and the delivery channel does not save you.

Paragraph 56: applicable is not the same as required

The Board then hands back the thing everyone forgets. These Guidelines deliberately do not analyse the exemptions, and "the applicability of this article does not systematically mean that consent needs to be collected". Much of the legal-alert coverage stops at paragraph 51 and reports a scare. The document itself refuses to.

The useful unit of analysis is not "short links" but the three things a short link can be. A bare redirect carries no identifier you added. A redirect plus UTM carries a campaign tag or a click id. A redirect plus pixel writes an advertising identifier on the way through. Treating them as one object is the mistake in almost every guide.

The UK regulator has a name for the middle row, and it is worth having in the ICO's own words rather than a summary of them. From the impact assessment the ICO published alongside the guidance: "Link decoration refers to the practice of adding extra information to the URL in a link that someone clicks on. This doesn't change the destination of the link but provides a way to pass additional information to the destination site beyond what is essential to navigate to the page that the user wants to visit." Navigational tracking is the next step, using that decoration to recognise a visitor to one site as the same person on another, for example by putting a user id in the URL. Read those two next to your last campaign and you will know which row you are in without a lawyer.

Tap to enlarge

Where the regimes really split

Read down the columns rather than across the rows and a pattern falls out. Europe and the UK regulate the act of touching the device, which is why a cookieless redirect is arguable there at all. The US, Brazil and India regulate the data, so the same redirect is judged on whether the fields are personal and whether you told people. A single "GDPR compliant shortener" badge is close to meaningless: the two families ask different questions.

For a bare redirect, everything narrows to one field: the IP address. Every other value arrives as ordinary request metadata. The IP is the one the EDPB singled out.

Tap to enlarge

Paragraphs 54 and 55, read carefully

The Board accepts that some providers track navigation using the IP alone and 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". Then comes the load-bearing sentence: access to an IP triggers 5(3) only "in cases where this information originates from the terminal equipment of a subscriber or user". Carrier-grade NAT means that is not always true, while a static outbound IPv4 from a home router, and IPv6 addresses because they are partly defined by the host, do fall inside. The burden then lands where you would not want it: "unless the entity can ensure that the IP address does not originate from the terminal equipment of a user or subscriber, it has to take all the steps pursuant to the Article 5(3) ePD".

Be honest about what that means operationally. When your redirect answers a request you do not know whether the address in front of you is a carrier NAT egress or a fixed IPv6 prefix belonging to the visitor's own router. You cannot ensure the negative, so on this reading your defence has to be an exemption, not a technical argument. Anyone saying "we only log IP-derived country, so ePrivacy does not apply" has skipped paragraph 55.

What dropping the address does, and what it does not

Dropping the IP after the country lookup, or hashing it, is real data minimisation and it matters for retention and breach exposure. It does not retroactively un-touch the device: the access, if any, happened when the address was received, not when it was written to disk. Flyn's public commitment is stated on the GDPR page as "IP addresses are used for geo-lookup only and never stored in analytics", and the privacy policy puts it as "We do not collect or store the clicker's IP address beyond the initial geo-lookup". That is a minimisation claim about storage, not an ePrivacy exemption, and we do not present it as one. Keep the two arguments apart in your own documentation too.

Vendor-neutral analysis is only useful if somebody puts their own product on the table, so here is ours, classified against the law rather than sold as a feature. Storage and retention mechanics live in the link security and retention guide and on the GDPR-ready links page.

The current behaviour, stated plainly

As of 10 September 2026, a Flyn short link is a 302 redirect that sets no cookie. Earlier builds set a 90-day first-touch attribution cookie on requests to the site, short links included; that cookie is now skipped on short-link requests, so a click writes nothing to the browser at all. Every short link is served with Cache-Control: private, no-store, verified live on 10 September 2026, so no shared cache holds the redirect and each click is resolved fresh. Hits from known crawlers, link-preview fetchers and headless browsers are screened by user agent before they are counted, and reported separately as filtered bot traffic on every plan.

The fields, classified

The slug is not an identifier about the visitor

A Flyn slug is letters, digits, hyphen and underscore, up to 100 characters, unique per domain, defaulting to a random six-character id. It identifies the link, not the person who clicked it, which is the distinction paragraph 49 draws: a slug is the resource, so it is entirely relevant to resource identification. Encode a subscriber id into it, or hand every recipient a unique link, and you have built the thing paragraph 49 describes, by choice. Check what you shipped with the link inspector or the URL expander.

The redirect is not what makes this a consent question. What you chose to write into the URL is.

Everything above is an argument about a redirect, and until now this page had no data about what redirects actually do. So we measured it. On 11 September 2026 we fetched one live short link on each of ten services with a desktop Chrome user agent, did not follow redirects automatically, and recorded each service's own answer: the status code, every Set-Cookie header with its full attributes, Referrer-Policy, Cache-Control and the hop chain. Only the first hop, the shortener's own response, is attributed to the shortener. Cookies set later by the destination are not counted, because they are not the shortener's to set, and the URL expander will show you how often the destination is a third host entirely.

Eight of the ten sent at least one Set-Cookie header on their own redirect. The two that sent none were Flyn and ow.ly. That count is the least useful number in the dataset, and the rest of this section takes it apart, because the sentence "eight of ten set a cookie" treats a six month visitor identifier and a thirty minute bot-management token as one object. They are not one object, and a page that rounds them into a single slogan has stopped measuring and started campaigning.

The count matters at all for the reason this page has already given. Article 5(3) is about storing information in terminal equipment, and a Set-Cookie header on the redirect response is exactly that, with none of the IP-origin difficulty that makes the bare-redirect case arguable. So the consent question does not wait for the destination to do anything. For these eight it is decided at the hop, on the shortener's own domain, before the visitor has reached the page they asked for.

Tap to enlarge

Four different things, not one number

Two are durable identifiers. bit.ly answered 301 and set _bit on Domain=bit.ly with an expiry of 10 March 2027, about six months out, carrying no HttpOnly flag, so script running on bit.ly can read it. clck.ru answered 302 and set Yandex's _yasc on .clck.ru with an expiry of 8 September 2036, about ten years out, also without HttpOnly. A value with that much persistence, scoped to a whole domain and readable by script, is the kind of storage the EDPB paragraphs above are written about. Neither service is hiding anything: these are analytics products, and this is how an analytics product recognises a browser it has seen before.

One is a per-click identifier that names the link. buff.ly answered 302 and set dub_id_buff.ly_2uy0SVo with Max-Age=3600 and Path=/2uy0SVo. One hour, scoped to that single short link, with the link's own code inside the cookie name. It is far shorter-lived than the first two and much narrower in scope, and it is also more specific, because it records which link this browser clicked. That is the conversion-attribution pattern rather than a site-wide visitor id, which makes it a different purpose to justify rather than automatically a lighter one.

Two set only a bot-management cookie, and this is where the strictly-necessary argument is strongest. tinyurl.com and is.gd set nothing but __cf_bm, Cloudflare's bot-management cookie, HttpOnly and Secure, expiring about thirty minutes out. Script cannot read it, it is scoped to the shortener's own domain, it is gone within the hour, and its job is separating automated traffic from human traffic at the edge. Whether a security measure of that kind clears the Article 5(3) bar is still an argument somebody has to make, but it is a genuinely different argument from the one a six month or ten year identifier would need, and collapsing the three into "cookies on the redirect" is the error this section exists to avoid. Worth saying plainly: neither service picked a tracking cookie here. What we measured is their CDN's defence, not their analytics.

Two set session plumbing. cutt.ly answered 301 and set PHPSESSID with Secure and no expiry at all, which makes it a session cookie the browser drops when the session ends. da.gd set DaGdSession_0 with Max-Age=2592000, thirty days, and HttpOnly. Session cookies are the classic candidate for the Directive's second exemption, but being called a session cookie is not the test. The test is whether the storage is strictly necessary to provide the service the user asked for, and thirty days is a longer thing to justify on a one-hop redirect than a per-visit cookie is.

And one cookie a browser would throw away. youtu.be answered 303 and sent GPS with Domain=.youtube.com, about thirty minutes, Secure and HttpOnly. The header came from the host youtu.be, which does not domain-match .youtube.com, and RFC 6265 section 5.3 tells a user agent to ignore a cookie whose domain attribute does not match the host that sent it. We recorded the header because recording headers is what the scan does, and we are not going to quietly count it as storage: on the strictest reading, storage actually lands on seven of the ten, not eight. That is precisely the detail that vanishes when a count becomes a headline.

Which exemption would have to be argued

We are not going to tell you which of these is lawful. That turns on each service's purpose, its notice, its jurisdiction and facts no single HTTP response can show, and the next section is a framework rather than a verdict. What a response header can tell you is which exemption a service would have to reach for, which is a useful thing to know before you choose where to send your audience.

Where this lands on the scenario table

Read the scan against the three-scenario table above and most of this sample is not in the row it is marketed in. The bare redirect, the genuinely arguable case this whole page is built around, is where two of ten services actually sit. The other eight are in the third column on the strength of their own headers, before a pixel fires or a destination loads: something was written to the device by the shortener. None of the law needs re-deriving for them, because the table already says what that column means in each regime. What the scan changes is who is standing in it.

It also answers from the other end a question the FAQ below takes on. If the destination sets cookies, that is the destination operator's responsibility under their own notice. The scan is about the other half: the shortener's own hop, on the shortener's own domain, which no notice of yours covers. Eight of ten made that choice on behalf of you and of everybody who clicked a link you shortened, and it will not appear in your consent banner, because it does not happen on your site.

Where Flyn sits, and what that row does not say

Flyn is one of the two services in the sample that set nothing, and it is worth being precise about what that means rather than what it sounds like. The link we measured answered 302 with no Set-Cookie header, Cache-Control: private, no-store, and Referrer-Policy: strict-origin-when-cross-origin, which is the modern browser default rather than a looser value. That matches the field-by-field account above, arrived at on a different day by a different method, which is the only reason we are comfortable publishing our own row at all.

Three qualifications, because a vendor's own row is the one to distrust. First, the link we tested was a live customer link served on a Flyn custom domain rather than a link on our main short domain, so the row describes how the redirect behaves on a customer's own host. Second, two later hops in that customer's chain did set __cf_bm, and those belong to the customer's own webhook and landing page rather than to Flyn; we did not count them against anybody and neither should you. Third, ow.ly reached the same result on the same measurement, so setting no cookie is not a Flyn-only property and we will not present it as one.

One more header finding from the same scan

Only four of the ten sent any Referrer-Policy on the redirect: bit.ly, buff.ly, ow.ly and Flyn. Two of those four sent a policy looser than the modern browser default of strict-origin-when-cross-origin. bit.ly sent unsafe-url and buff.ly sent no-referrer-when-downgrade. A looser policy means the destination can be given the full referring URL, path and query included, which can be more than a direct click would have sent. We re-checked bit.ly on six independent live links and got unsafe-url every time. This is not an Article 5(3) question, because nothing is stored on or read from the device, but it is a data-sharing question about whoever the destination turns out to be, and you can check a link before you send it with the redirect checker or the security headers checker.

The method, and what ten links cannot tell you

The method in one paragraph. Ten services, one live short link each, one fetch per link on 11 September 2026, from one location, with one desktop Chrome user agent, redirects not followed automatically so that every hop was recorded separately. Three of the links were minted by us to a destination we control (tinyurl.com, da.gd, clck.ru), five were real live links found in a public crawl sample (bit.ly, is.gd, ow.ly, buff.ly, cutt.ly), one was a live customer link on a Flyn custom domain, and one was a well known public video (youtu.be). Only the first hop is attributed to the shortener. Every figure quoted above is a response header, not an inference from one, and the reporting discipline is the one we used for our bot-share measurement: publish the method, the sample and the ceiling alongside the number.

Now the limits, which are wider than the findings. This is ten services, one link each, one fetch. It is not a survey of the industry, and no sentence on this page should be read as one. Header behaviour is mostly a property of the service rather than of the individual link, and we re-checked bit.ly across six independent live links with an identical result, but a single fetch cannot see per-region variation, per-account settings, logged-in behaviour, or what any of these services do when the request comes from a phone. A cookie absent on one fetch is not proof that a service never sets one. A cookie present on one fetch is evidence about that service's edge on that day, not a permanent characteristic of it.

Two services we wanted are missing. v.gd and dub.sh are not in the table because no live link for either turned up in the sample we drew from, and we would rather publish ten named services and the two we could not reach than pad a table to a round number. Two rows also measure something slightly different from a clean redirect: tinyurl.com sent our link to its own deprecated-preview page rather than to the destination, and da.gd answered 200 with no Location header at all for a link we minted on it, so its cookie was set on a page rather than on a redirect. Both sit in the table as measured and flagged, rather than dropped for being untidy.

And the obvious conflict: we sell a shortener, and the scan that puts eight competitors in a busier column than ours was run by us. The only real answer to that is that every value in the table is a response header you can fetch yourself, on any link, in one command, today. Do that before you believe the number, including the row with our name on it.

Assume you are in scope. Paragraph 56 says that settles nothing, so this is where the real work happens.

Tap to enlarge

The two exemptions in the Directive itself

Article 5(3) exempts technical storage or access for "the sole purpose of carrying out the transmission of a communication over an electronic communications network", and storage or access "strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service". Germany reproduces both in TDDDG section 25(2), and France transposes the same rule in Article 82 of the Loi Informatique et Libertes, read by the CNIL as prior consent for reads and writes on a terminal, with narrow exceptions.

Where a redirect sits against them

Delivering the destination page is the service the user explicitly requested when they tapped the link, so resolving the slug and issuing the 302 is a strong strictly-necessary case. Counting the click for your own reporting is not: the visitor asked to reach a page, not to be measured. That is the same split regulators apply to first-party analytics cookies. If your link analytics exist to help you rather than the visitor, the exemption argument is weak.

France and Italy: two 2026 texts that stop at the pixel

Both national regulators published something new on email tracking in 2026, and the useful finding is what is absent from them. The CNIL adopted a Recommendation on tracking pixels in emails on 12 March 2026: consent is needed for open-rate analysis used to measure and optimise campaigns, while security checks tied to authentication and individual open-rate measurement used only for deliverability and list hygiene can be exempt. It says in terms that it is limited to tracking pixels in emails, and the French noun for a click does not appear in the document at all: the only clicking it discusses is a person clicking a hyperlink to reach information or to confirm consent. Italy is the same shape. Provision no. 284 of 17 April 2026, published in Gazzetta Ufficiale no. 98 on 29 April 2026, sets out guidelines on tracking pixels in email, and its most useful carve-out for anyone counting anything is that consent can be unnecessary where the pixel serves a "conteggio di tipo statistico che misuri la percentuale globale di apertura dei messaggi", a statistical count of the overall open rate, on condition that the measurement is anonymised so that it cannot become personalised: the Garante suggests one pixel identical for every recipient of a campaign rather than a per-recipient one, and anonymisation of the related technical data including the IP address.

So neither 2026 text covers the click redirect this page is about. That is a gap in the letter of those documents rather than a safe harbour: the reasoning in both, that an instruction to the terminal to send an identifier back is a read operation, is the same reasoning the EDPB applies to a tracking link. What Italy does add is a template worth copying anywhere: aggregate, non-individual counting with the identifying technical fields anonymised is the version of measurement regulators have been willing to bless.

The UK's statistical-purposes exception

The Data (Use and Access) Act 2025 added new exceptions to PECR, commenced by SI 2026/82 on 5 February 2026. Section 112 of the Act rewrote regulation 6 and Schedule 12 inserted a new Schedule A1 holding the exceptions, which is the structure the government's own PEC Regulations factsheet describes. Paragraph 5 of that Schedule is the statistical one, and it is worth reading rather than paraphrasing. It applies where "the sole purpose of the storage or access is to enable the person" to "collect information for statistical purposes about how the service is used with a view to making improvements to the service", or the same for a website through which the service is provided. It applies only where "any information that the storage or access enables the person to collect is not shared with any other person except for the purpose of enabling that other person to assist with making improvements to the service or website". And it attaches two more conditions: clear and comprehensive information about the purpose, and a "simple means of objecting, free of charge" that the person has not used.

Put your own case against those limbs before you claim the exception. A shortener or a marketer measuring a campaign on behalf of a customer probably fails the sole-purpose limb and the no-sharing limb at the same time, because the statistics exist for the campaign rather than for the service and they are handed to someone else for their own use. Measurement that genuinely feeds improvements to your own redirect service, and stays with you, is the case the paragraph was written for. The same paragraph also says that, for this exception, gaining access "does not include a reference to collecting or monitoring information automatically emitted by the terminal equipment", which is a sentence a visitor's IP address walks straight into; we are not going to pretend its effect is settled, and the ICO's finalised guidance on the use of storage and access technologies, published on 29 April 2026, is where to watch it. Narrowed to its real case, this is still genuinely new headroom for UK-facing first-party measurement, and it has no EU equivalent, so a single European answer for both markets is now wrong in one of them.

You do not need a legal opinion to get the basics right, but you do need to know what you shipped. Run this before the send, not after the complaint.

Tap to enlarge

1. Know which of your links carry an identifier. A random slug does not. A per-recipient link, a click id or a subscriber value in a UTM does, and that is the line paragraph 49 draws.
2. Confirm the redirect writes nothing to the device. Follow one of your own links with the redirect checker and read the response headers yourself, rather than taking any vendor's word for it, ours included.
3. Write the purpose down before you pick a basis. Delivering the page, measuring your own campaign and profiling a person are three purposes with three answers; mixing them in one sentence is how compliance documents become indefensible.
4. Keep personal data out of the URL you build. An email address in a campaign parameter turns a routine click log into a personal-data store. Clean URLs with the URL cleaner and audit what arrives with the UTM parser.
5. Say it in a notice people can reach. Name the shortener, the fields, the retention window and the route to object. If you are in the UK relying on statistical purposes, that route is a condition of the exception, not a nicety.

If you route by country or device, that decision uses the same IP-derived signal, so document it in the same place: see geo-targeted links versus redirects and geo-targeting, a paid feature on every plan above Free.

The gap between what the law covers and what regulators pursue is wide, and pretending otherwise helps nobody. The measured version, as of 10 September 2026.

Europe and the UK: banners, not redirects

European and UK enforcement under the storage-and-access rules has overwhelmingly targeted consent banners that fire trackers before acceptance or make refusal harder than acceptance. The fines and the banner mechanics behind them are set out in our pixel and consent guide and are not repeated here. What matters for a redirect is the negative: we know of no published decision against a URL shortener for the bare-redirect case, and it would be dishonest to imply the risk equals an unconsented advertising pixel. What changed is the paper trail: after Guidelines 2/2023, "there was no cookie" is not a complete answer in a DPO questionnaire.

California: the pen-register theory and SB 690

The livelier US story is CIPA. Plaintiffs argue that ordinary website tracking software collecting IP addresses, device identifiers and routing data is a pen register or trap and trace device under Penal Code section 638.51, which requires a court order, with a consent exception in subdivision (b). Settlements have followed, including a 3.85 million dollar class settlement granted final approval on 26 June 2026 over trackers on the Los Angeles Times site and apps, itself now under appeal. On 28 August 2026 the California Legislature passed S.B. 690, which would remove the private right of action for section 638.51 website and application claims and leave them to the Attorney General. As we write it is with the Governor, who has until 30 September 2026 to act, so check where it landed before you rely on it.

The realistic risk if you run ten links

If you are a solo operator, your practical exposure is not a headline fine. It is a procurement questionnaire, an affiliate network's compliance review, or a subscriber complaint you cannot answer because nobody wrote down what your links collect. The fix for all three is cheap: know your fields, know your purpose, say both in public. Start from how click tracking works and what the dashboard reports, and if the numbers look wrong, check clicks not showing before blaming the law.

Not legal advice

This is general information, not legal advice. Whether your setup needs consent depends on your jurisdiction, your purpose, your audience and facts only you can see, and the central question (whether the identifier in your URL originated from the visitor's device) is one no vendor can answer for you. Use this page to brief a qualified privacy professional faster, not instead of one, and read it alongside our GDPR page, our privacy policy and our terms.