A GDPR-friendly URL shortener does four things: it signs a data processing agreement that covers Article 28(3), it stores as little click data as the purpose needs, it can delete that data on request, and it does not fire third-party pixels during the redirect. Everything else on a pricing page ("GDPR compliant", a badge) is marketing until you can see those four in writing.
A click creates a log row: IP address, timestamp, user-agent, usually a referrer. Under Article 4(1) that can be personal data, and the CJEU said as much for dynamic IPs in Breyer (C-582/14). Your shortener holds that log, so it is a processor and you are the controller. This post is the short version of the contract review: ten checks, what three well-known vendors publish, and where Elido itself falls short. For the legal reasoning article by article, read the GDPR for URL shorteners cornerstone. For where your other marketing tools store data, see EU data residency for marketing tools; I won't repeat that here.
What GDPR Asks of a Link Shortener
Four obligations land on the shortener side, and each one maps to something you can ask for.
A contract that meets Article 28(3). Article 28(3) requires documented instructions, confidentiality, security, sub-processor controls, help with data subject requests, help with breach and DPIA duties, deletion or return at termination, and audit rights. No such contract, no EU deployment.
A lawful basis for analytics. The redirect is necessary to deliver the link. Recording the click for reporting is a separate operation. Most teams rely on legitimate interest (Article 6(1)(f)) for plain counts. Once the redirect loads an ad pixel, you are in consent territory.
Minimisation. Article 5(1)(c) limits you to what is necessary. Country, device class, referrer and timestamp answer most campaign questions. The full IP and a raw user-agent string usually do not earn their place.
A lawful transfer path. If click data leaves the EEA, Articles 44 and 46 apply: SCCs with a transfer assessment, or a Data Privacy Framework certification, which remains contested.
What Bitly, Rebrandly and TinyURL Publish
I read each vendor's own legal pages on 2026-10-24 (accessed 2026-10-24). Where a page did not load or did not say, I state no claim.
| Vendor | Data location | Transfer mechanism | DPA |
|---|---|---|---|
| Bitly | Privacy policy says data "may be transferred outside the European Union and the European Economic Area, including, but not limited to, the United States" | SCCs, and a stated EU-U.S. DPF certification | The privacy policy does not mention a DPA; it names a joint controller agreement between Bitly Inc. and Bitly Europe GmbH |
| Rebrandly | DPA Schedule 1: AWS servers "located mainly in the United States"; section 6.3.1: primary processing facilities in the US; no EU region named | SCCs (Module Two, controller to processor); DPF not mentioned | Yes, the DPA forms part of the Subscription Agreement (the Terms of Use) |
| TinyURL | Policy pages did not load for me (only a page title came back) | Not stated | Not stated |
Sources: Bitly privacy policy, Rebrandly DPA, TinyURL terms and privacy policy.
Read that table for what it is. Bitly and Rebrandly both rely on recognised transfer tools and say so openly; neither publishes an EU-only processing commitment on the pages I checked, though a custom enterprise contract may offer one. For TinyURL I can't tell you anything, because the pages I fetched returned no policy text. If it matters to you, ask TinyURL for the DPA and sub-processor list directly and wait for the answer before you buy. Pricing is a separate question and I have not verified any vendor's plan prices for this post.
Ten Checks Before You Sign
Put each of these to the vendor in writing. Each one tests a specific article.
1. Where is click data stored, and is that a contract term?
Ask for the region, not the cloud brand. "AWS" is not an answer. Then ask if the region is in the contract or only in current practice, which the vendor can change.
2. Does the DPA cover all of Article 28(3)?
Read it against the eight points. Look hard at sub-processor engagement and audit rights; vague "industry-standard security" language in their place is a warning sign.
3. Are sub-processors named, with regions and a notice period?
Every sub-processor lengthens the transfer chain. A short, current list with regions can be reviewed in one sitting. Ask how much notice you get on a new one and whether you can object.
4. What exactly is stored per click?
Get the field list. Is the IP stored in full, truncated or hashed? Is city-level geolocation kept? Default minimisation is the right design; opt-in minimisation leaves the risk with you.
5. Does the redirect load any third-party script?
Pixel injection at redirect time for EU visitors needs consent first. Open the Network tab, click a test link in a clean browser profile, and see what loads before the destination.
6. How does erasure work on click data?
Article 17 says "without undue delay". Click rows seldom carry a name, so ask how the vendor finds and deletes the rows for one person, and what the turnaround is.
7. What is the breach notification window?
You have 72 hours to tell your regulator after becoming aware. Your processor needs a shorter, numeric commitment in the DPA. "Promptly" is not a number.
8. Does the redirect set cookies or persistent identifiers?
A redirect that derives country and device from request headers and sets nothing on the browser is easy to defend. One that sets an identifier needs a consent gate. Check the response headers yourself.
9. Can recipients find out about the tracking?
Article 13 transparency is mostly your job as controller: your privacy notice must cover the link-tracking chain. A vendor policy written from the vendor's point of view will not do it for you.
10. Can you export and delete without a ticket?
Export click events, delete links with their history, and close the account with documented deletion. If any of those needs a support request, get the turnaround in the contract.
The Tradeoffs
Minimised data costs you some analytics. Without the full IP and raw user-agent you lose city-level precision and cross-session identity. For campaign attribution, country, device and referrer are enough. For person-level retargeting, use server-side conversion forwarding keyed on an identifier the user already gave you, such as a login ID, rather than tracking at the redirect.
You also give up some features. Pixel injection and cross-domain tracking depend on collection that sits badly with minimisation. A GDPR-friendly set-up keeps the redirect plain and moves measurement to the conversion event, where you have a direct relationship with the user. Procurement still takes effort: expect to read the DPA, the sub-processor list and the erasure process whichever vendor you pick. See also click attribution after Safari ITP and Schrems II and tracking pixels.
Where Elido Stands Today
I checked these against the code on 2026-11-12, and some of it is not flattering.
- Click data: the edge truncates the visitor IP (IPv4 to /24, IPv6 to /48) before the click is stored. Country, region, city and approximate coordinates are derived first and kept, and the full user agent is stored. No setting keeps the full IP, and a no-personal-data mode exists through the API only.
- Pixels: a plain redirect loads no third-party script. A link can opt in to a splash page that fires Meta, Google, LinkedIn or TikTok pixels before redirecting; if you use that for EU visitors, you need a consent basis. Click forwarding to GA4, Mixpanel, Klaviyo, Brevo or Datadog sends click events to those vendors, so list them in your records.
- Erasure: the admin data-subject workflow can export and erase an account (the user record is anonymised; billing records are retained under Article 17(3)(b)). The same request can delete the click data of workspaces the person alone owns, and, for a link visitor, every click from their truncated network, narrowed to one browser when they give the user agent. Click rows also expire on a per-plan window: 90 days on Free, one year on Pro, two years on Business.
- Contract and sub-processors: a DPA with EU SCCs is available on request on every plan, including Free; it is not accepted at checkout and no download is published. The sub-processor list (13 vendors) and privacy policy are published. Data is stored in the EU, but redirect nodes outside the EU still process visitor requests and there is no per-workspace region choice yet. Read them against checks 1 to 3 yourself, and see the trust page for attestations.
If you are leaving another vendor, the Bitly migration playbook covers the link import and DNS handover. After the cut-over, send the old vendor an erasure request for your workspace, update your privacy notice with the new processor, and review any consent banner that referred to the old tool's tracking. For plans, see pricing.
What to Verify Before Trusting a "GDPR Compliant" Claim
The label is not regulated and carries no legal weight. The artefacts that do: a DPA mapped to Article 28(3), a sub-processor list with regions, a field-level description of what a click stores, an erasure process you can test, and a numeric breach window. If a vendor can't send these within a business day, treat the badge as copy.
Related on the blog
Frequently asked questions
Is a URL shortener a data processor under GDPR?
Yes, in the usual set-up. You decide why and how clicks are measured, so you are the controller, and the shortener processes click data on your instructions. That needs a written Article 28(3) contract.
Is an IP address in a click log personal data?
Yes. The CJEU held in Breyer (C-582/14) that a dynamic IP address is personal data when the holder has legal means of identifying the person behind it. A shortener that logs the full IP next to a timestamp is in that position.
Do I need consent to track clicks on short links?
Not always. Server-side click counting with minimal fields is often grounded in legitimate interest under Article 6(1)(f), but loading ad pixels or setting identifiers for EU visitors usually needs consent, and ePrivacy rules apply to the device access.
Does a US-hosted shortener break GDPR?
Not automatically. Transfers to the US are lawful with a valid mechanism such as Standard Contractual Clauses plus a transfer assessment, or a Data Privacy Framework certification. They add paperwork and legal risk that an EU-hosted tool does not.
What should a shortener's DPA contain?
Everything Article 28(3) lists: documented instructions, confidentiality, security, sub-processor rules, help with data subject requests, help with DPIAs and breaches, deletion or return at the end, and audit rights.
How do I erase one person's click data from a shortener?
Ask the vendor how click rows are identified and deleted. Click logs rarely hold a name, so erasure usually means deleting by IP, link or time range. If the vendor can only route this through a support ticket, get the turnaround in writing.
Try Elido
Paste a URL, get a working short link
No signup. Link lives for 30 days. Sign up to keep it forever.
No signup needed. Sign up free for 50 links a month.