GDPR-friendly URL shorteners — what to look for in 2026

Every redirect through a URL shortener creates a data processing event. The click event contains at minimum an IP address, a timestamp, and a user-agent string. Under Article 4(1) of the GDPR, that combination can constitute personal data — the CJEU confirmed in Breyer (C-582/14, 2016) that dynamic IP addresses are personal data when an organisation has a realistic means of identifying the individual behind them. Your shortener has that means: it controls the redirect log.

This post is a practical checklist for evaluating whether a URL shortener is genuinely GDPR-friendly. I'll walk through what the regulation actually requires, where popular providers fall short, what to look for in a compliant tool, and the tradeoffs involved. The article references are to Regulation (EU) 2016/679, the GDPR as amended.

A URL shortener sits in the data flow between your campaign and your customer. When someone clicks a short link, the shortener sees the click before the destination page does. That makes the shortener a data processor under Article 4(8): it processes personal data on your behalf. You are the controller; you decide the purpose and means of the tracking. The shortener carries out the operation under your instructions.

That split creates four concrete obligations you need the shortener to meet:

1. A written contract covering Article 28(3)

Article 28(3) lists eight requirements any processor contract must include: processing only on documented instructions, confidentiality, appropriate security, sub-processor disclosure, assistance with data subject rights, assistance with security and DPIA obligations, deletion or return at termination, and audit rights. A shortener without a Data Processing Agreement (DPA) that addresses each of these is not procurement-ready for an EU deployment.

2. Lawful basis for the click-tracking layer

The redirect itself — taking a click and routing it to the destination — is arguably necessary for the service. The analytics layer sitting on top of that redirect — recording the click for attribution, campaign measurement, retargeting — is a separate processing operation that needs its own lawful basis under Article 6. Most B2B teams ground campaign analytics in legitimate interest under Article 6(1)(f); if the shortener injects third-party retargeting pixels at redirect time, the basis shifts to consent under Article 6(1)(a), which means you need a consent mechanism before the first click.

3. Data minimisation

Article 5(1)(c) requires that data collection be "adequate, relevant and limited to what is necessary". For a shortener, this principle applies directly to the click-event schema. You need the country-level geo, the device category, the timestamp, and a click identifier. You do not need the full IP address past the moment of the redirect. You almost certainly do not need the full user-agent string — a parsed device.type / device.os tuple carries the attribution signal without being a fingerprinting vector.

4. International transfer compliance

If the shortener stores or processes click events outside the EEA, Article 44 and Article 46 apply. Transfers to the US require either Standard Contractual Clauses (SCCs) plus a Transfer Impact Assessment, or participation in the EU-US Data Privacy Framework, which is itself the subject of pending litigation. An EU-hosted shortener avoids this problem entirely.

Where popular shorteners fall short#

Bitly#

Bitly's primary data plane is in the United States. Per their public documentation, international data transfers from the EEA rely on Standard Contractual Clauses. The DPA is available, but it is not pre-signed in the standard contract — enterprise customers negotiate it separately, which adds procurement lead time. EU-only data residency is not a standard offering; it is a custom-contract conversation.

Two less-discussed issues: Bitly's analytics dashboard integrates with third-party attribution services, and some plan tiers enable retargeting pixel injection at the redirect layer. If retargeting pixels fire before the user has consented, that is a Article 6 compliance problem for you as the controller. The shortener is the processor, but the controller bears primary responsibility for having the correct lawful basis in place.

Rebrandly#

Rebrandly is headquartered in Dublin, which sounds EU-friendly, but the operative question is where data is processed, not where the company is incorporated. Per their DPA (accessed May 2026), data transfers from the EEA to the US rely on SCCs. EU-only processing is available to enterprise customers on custom terms. The standard contract does not bind the data to EU infrastructure. For teams that need a contractually enforceable residency clause off the shelf, Rebrandly requires a custom negotiation.

Rebrandly also supports third-party retargeting pixels natively on most plans. The marketing value is real; the compliance implication is that any pixel firing at redirect time for EU subjects needs a consent basis, not a legitimate interest basis, because behavioural profiling for advertising sits outside the legitimate interest boundary for most supervisory authority interpretations.

TinyURL#

TinyURL offers a clean free tier and is a widely-used consumer shortener. It does not publish a sub-processor list. The standard terms do not include a DPA that meets Article 28(3). The analytics layer is rudimentary and hosted in the US. For B2B or marketing teams with EU subjects in their audience, TinyURL is not procurement-ready.

The general US-hosted shortener problem#

Many providers operating primarily for US customers treat GDPR compliance as a checkbox rather than an architectural constraint. The signs to watch for: a "GDPR compliant" badge on the pricing page with no link to a DPA, a sub-processor list that doesn't name hosting regions (just hyperscaler names without regions), an erasure process that routes through support rather than a documented API endpoint, and no mention of IP truncation or data minimisation defaults.

"GDPR compliant" as a marketing claim means nothing without a DPA that maps to Article 28(3), a sub-processor list that is current and region-specific, and evidence that the default data collection posture applies minimisation rather than requiring you to opt into it.

These are the ten questions to put in writing before signing a contract with a URL shortener that will process click data on EU subjects.

1. Where is the data processed, and is that a contractual commitment?#

Ask for the hyperscaler region — not just the cloud provider name. "AWS" is not an answer; "AWS eu-central-1 (Frankfurt)" is. More importantly, ask whether that region is a binding clause in the standard contract or an operational practice that can change without your consent. Under Article 44, transfers outside the EEA need a legal basis; you want the residency commitment in the contract so you do not have to redo the analysis every time the vendor updates their infrastructure.

2. Is the DPA pre-signed, and does it cover Article 28(3) in full?#

A DPA that ships pre-signed in the standard contract signals that the vendor treats GDPR compliance as a baseline, not a negotiation. Read the DPA against the eight sub-paragraphs of Article 28(3). Each must be addressed. Pay particular attention to paragraph (d) — sub-processor engagement — and paragraph (h) — audit rights. Generic language like "we use industry-standard security practices" in place of the concrete obligations is a red flag.

3. How many sub-processors, and are they named with regions?#

Every sub-processor is an additional link in the transfer chain. A short list with named regions (Hetzner eu-central FRA, Postmark US-East, etc.) is auditable in a single review. A long list with vague vendor names is a maintenance burden and a residency risk. Under Article 28(2), each sub-processor must accept the same data protection obligations as the processor. Ask what the notification period is for new sub-processors and whether you have a right to object.

4. Does the shortener truncate or hash IP addresses before storing them?#

Full IP address storage is rarely necessary for the analytics use cases a shortener supports. Country-level geolocation and bot-detection can be performed at redirect time from the full IP and the result stored; the raw IP can then be discarded or truncated. Under Article 5(1)(c), storing more data than the purpose requires is a breach of the data minimisation principle. Ask whether IP truncation or hashing is the default, or whether you must opt into it. Default minimisation is the right architecture; opt-in minimisation shifts compliance risk onto you.

5. Does the redirect inject any third-party scripts or pixels?#

Some shorteners offer retargeting pixel injection as a feature: when a visitor clicks your short link, the shortener loads a Meta Pixel, Google Tag, or similar third-party script before or during the redirect. For EU subjects, loading a third-party behavioural tracking script without prior consent is a violation of Article 6 and, depending on whether cookies are set, of the ePrivacy Directive. If your shortener offers pixel injection, that feature must be disabled or gated on consent for EU traffic. If the vendor cannot confirm that no third-party scripts load at redirect time by default, test it yourself with the Network tab open.

6. Is there an API endpoint for right-to-erasure requests?#

Article 17 gives data subjects the right to have their personal data erased "without undue delay" when specific grounds apply. When you receive an erasure request that relates to click data your shortener holds, you need a mechanism to act on it. An API endpoint that accepts a subject identifier and deletes associated click events is the operationally correct answer. Erasure-by-support-ticket is not "without undue delay" in most supervisory authority interpretations and is not a scalable pattern at any meaningful click volume.

The complication is that click events often live in an append-only analytics database (ClickHouse, BigQuery, Snowflake). A vendor that stores click events this way needs to demonstrate that the deletion is real — a DELETE against the relevant partition — not just a soft flag. Ask for the vendor's Article 17 SLA and the technical mechanism behind it.

7. What is the breach notification SLA?#

Article 33 requires a controller to notify its supervisory authority of a personal data breach "without undue delay and, where feasible, not later than 72 hours after having become aware of it". For that clock to work, you need your processor to notify you materially faster — the industry norm is 24 hours from awareness to controller notification. Your DPA should specify this SLA. "We will notify you promptly" is not a number.

8. Does the shortener use cookieless, first-party analytics by default?#

Many shorteners build their own analytics dashboard on top of a third-party product analytics tool (Mixpanel, Amplitude, Segment) that is US-hosted and may set persistent identifiers in cookies or local storage. For the shortener's own product analytics (tracking your usage of the dashboard), that is a separate matter. The relevant question for click tracking is whether the redirect flow sets any cookies or persistent identifiers on the visitor's browser without consent.

A cookieless click event — one that derives country, device, and referrer from the request headers without setting any client-side state — does not require a consent mechanism for first-party analytics under most supervisory authority guidance, provided the data is processed under legitimate interest and the privacy notice is accessible. A redirect that sets a persistent identifier or loads a third-party tag requires a consent gate. Know which one your shortener uses.

9. Is there a transparency notice accessible to link recipients?#

Article 13 requires that individuals whose data is collected be informed of the processing at the time of collection, unless an exception applies. For click tracking on a short link, the practical question is: how does the person who clicks the link know their click is being tracked, and where can they read about it?

Most shortener deployments satisfy this through the controller's privacy notice on the destination page or in a cookie banner on the originating campaign page. The shortener as processor does not need to display its own notice to the clicker — but you as the controller need a privacy notice that covers the link-tracking processing chain. If the shortener's privacy policy is the only document that describes the processing, and it is written from the vendor's perspective rather than the controller's, you have a gap.

10. Can you download and delete your own data without contacting support?#

This is a practical test of whether a vendor actually operationalises the data subject rights they claim to support. You should be able to: export all click events for a workspace in a portable format, delete individual links and their associated click history, and terminate the account with documented deletion of all personal data. If any of these require a support request rather than a self-serve API or dashboard action, ask for the SLA and put it in the contract.

The tradeoffs involved#

GDPR-friendly architecture involves real tradeoffs, and being honest about them is more useful than pretending the compliance constraints have no cost.

Coarser analytics. A shortener that truncates IPs to /24 and discards the full user-agent string gives you country, device family, and OS — but not city-level targeting, not the individual browser fingerprint, and not the cross-session identity resolution that full-resolution data would enable. For most campaign attribution use cases, this level of resolution is sufficient. For retargeting at the individual level, you need a different approach — typically server-side conversion forwarding against a first-party identifier the user has already shared (email address, logged-in user ID), which does not require the shortener to track the individual at the redirect layer.

Smaller feature surface. Some of the most powerful shortener features — retargeting pixel injection, cross-domain tracking, deep integration with third-party ad platforms — are built on data collection practices that are hard to reconcile with data minimisation. A GDPR-friendly shortener tends to have a cleaner redirect that does less at the redirect layer and routes more to the conversion event layer, where the controller has a direct relationship with the user and can ground tracking in consent.

Procurement overhead. Choosing an EU-hosted shortener with a pre-signed DPA reduces the procurement cycle compared to a US-hosted vendor that requires a custom contract for EU residency. It does not eliminate the cycle. You still need to review the DPA, check the sub-processor list, validate the erasure SLA, and confirm that the IP-truncation and cookie defaults match your privacy notice. Estimate two to four hours of procurement work for a GDPR-friendly shortener versus two to eight weeks for a US-hosted vendor where EU residency requires custom contract negotiation.

How Elido approaches this#

Where it's relevant to this checklist, here is what Elido's standard deployment looks like.

Data residency. Elido processes click events on Hetzner infrastructure in Frankfurt by default. The residency is a binding clause in the standard customer contract, not an operational practice. Business+ customers can pin to other regions; the default does not transfer data outside the EEA.

IP truncation. Click events stored in ClickHouse contain the /24 (IPv4) or /48 (IPv6) network prefix, not the full IP address. Geo and bot-detection run on the full IP at redirect time and the full IP is discarded before the event is persisted. This is the default; you do not need to configure it.

Third-party pixels at redirect time. The redirect plane does not load any third-party scripts. Server-side conversion forwarding — sending attribution data to Meta CAPI, GA4, or similar — is an optional, separately-configured feature that uses first-party event data you POST to the Elido API, not a pixel injected at redirect time. These are architecturally different: one fires without the visitor's knowledge from the redirect, the other is a server-to-server call keyed on data the visitor already shared with you.

DPA. Elido's DPA is pre-signed in the standard customer contract. It addresses all eight sub-paragraphs of Article 28(3). Sub-processors are listed on the trust page with named regions. The legal/privacy page covers the processing chain visible to link recipients.

Right to erasure. Article 17 erasure requests propagate to the ClickHouse click-event store within 24 hours. The deletion is a partition-level operation, not a soft flag.

Cookieless analytics. The redirect plane does not set cookies. Click events are server-side only. The analytics dashboard Elido ships internally uses Plausible in cookieless mode for product telemetry; this is separate from the click-event recording for your campaigns.

What Elido does not yet have: SOC 2 Type II (in progress, targeted for H2 2026), a self-serve DPIA template for customers, and a fully-automated subject-access request API for less common right-of-access scenarios. For details on current attestations, see the trust page.

Migration checklist for switching from a non-EU shortener#

If you're currently using a US-hosted shortener and need to move to an EU-hosted one, here is a compressed operational checklist.

Before signing the new contract:

Read the new vendor's DPA against Article 28(3). Confirm all eight points are covered explicitly.
Check the sub-processor list. Confirm hosting regions are named, not just cloud providers.
Confirm the IP truncation default. Ask for written confirmation if it's not in the product documentation.
Confirm the Article 17 SLA and the technical mechanism.
Check whether retargeting pixels fire at redirect time. If so, confirm they can be disabled entirely or are gated on consent.

During migration:

Export your existing short links as CSV. Verify that custom slugs are preserved by the new platform before you touch DNS.
Provision all links on the new platform under the same custom domain and slugs before repointing the CNAME.
Allow 24–48 hours for DNS propagation after the CNAME switch. Both platforms will serve valid responses during this window if the slugs match.
Do not migrate historical click data from the old platform — the chain of custody for old click events stays with the old processor until you exercise deletion rights.

After migration:

Issue an erasure request to the old vendor for all personal data associated with your workspace. Confirm receipt and the deletion timeline.
Update your privacy notice to reflect the new processor, its sub-processors, and the new data residency.
Review any cookie banners or consent mechanisms that referenced the old shortener's tracking features. Adjust scope if the new platform's default collection is narrower.

The migrate from Bitly playbook covers the technical mechanics of the link import and DNS handover in more detail.

Any shortener can put "GDPR compliant" on a pricing page. The claim is not regulated and carries no legal weight on its own. The artefacts that carry weight are:

A DPA that maps to Article 28(3) sub-paragraph by sub-paragraph.
A sub-processor list that names vendors, regions, and the data categories shared.
A privacy notice accessible to link recipients that describes the processing chain — this satisfies Article 13.
Documented IP handling that confirms truncation or hashing before persistence.
An Article 17 erasure SLA with a named technical mechanism.
Independent attestation (ISO 27001 is the floor; SOC 2 Type II adds assurance for US/international procurement).

If a vendor cannot supply all of these in writing within one business day, the "GDPR compliant" claim is marketing copy rather than a documented compliance posture.

For the article-level legal analysis behind this checklist, the GDPR for URL shorteners cornerstone covers Articles 3, 6, 28, 30, 32, and 35 in depth with supervisory authority citations. Procurement-facing artefacts: Elido's privacy policy, terms of service, and pricing — the DPA is bundled into the standard contract at every paid tier.

What GDPR requires of a URL shortener#