If you share short links for clients, in a newsletter or from your social bio, every click sends a little data about a real person to whoever runs the shortener. Under the UK GDPR and the EU GDPR, that data is usually personal data, and you are usually the one responsible for it.
So people search for a "GDPR compliant URL shortener". Here is the honest answer: no tool can make you compliant. Compliance depends on what you collect, why, what you tell people and how you use the results. What a good shortener can do is keep the data it handles small, explain it clearly and put it in writing.
Below are ten things to check with any URL shortener. We make Weeny, so we are not neutral, but we use it as the worked example and quote our own policies word for word, gaps included. This is not legal advice, so do your own checks, and talk to a data protection adviser if you handle sensitive data.
The checklist
1. Cookies or scripts on the redirect
Some shorteners set a cookie or load a script during the redirect, to recognise returning visitors or to show ads.
Why it matters: in the UK, cookies are covered by PECR alongside the UK GDPR, and in the EU by the ePrivacy rules. A cookie that is not strictly necessary generally needs consent, and nobody sees a consent banner on a redirect.
Ask: does the redirect set any cookie? Does it load any script or pixel? Are there exceptions, such as password-protected links?
2. What click data is stored
Any shortener with analytics records something about each click: typically the time, IP address, user agent (the browser and device string), referrer and a location worked out from the IP.
Why it matters: data minimisation is a core GDPR principle. The less that is stored, the less you have to protect, explain and delete.
Ask: which fields are stored for each click, and which are only used at the moment of the click? Are forms and landing pages handled the same way as links?
3. How IP addresses are handled
Why it matters: an IP address can be linked back to a household or a person, so storing full IPs indefinitely is the riskiest pattern. Hashing or truncating them helps, but a hashed IP is pseudonymised data, which usually still counts as personal data under GDPR. Hashing lowers the risk; it does not take the data out of scope.
Ask: are IPs stored in full, truncated or hashed? Are they ever shown or sent anywhere, such as a webhook or an export?
4. How long data is kept
Why it matters: storage limitation is another core principle. "We keep it for as long as necessary" is not a period you can repeat to a client.
Ask: is there a stated retention period? Does it apply to every field or only some? Is it enforced automatically? When did it take effect, and does it cover older data?
5. Ads
Why it matters: some shorteners show a preview page with third-party ads before the destination, and ad networks bring their own cookies and data collection.
Ask: are ads ever shown to people who click my links, on any plan?
6. Sale or sharing of data
Why it matters: if click data is sold or shared with advertisers, your audience's data ends up with companies you have never heard of.
Ask: does the policy say plainly that click data is never sold or rented?
7. A DPA, and whether it matches the privacy policy
Why it matters: the GDPR expects a Data Processing Agreement (DPA) between a controller and a processor, setting out what the processor may do with the data for you. If the DPA and the privacy policy describe the data differently, you need to know which promises are actually in the contract.
Ask: is there a DPA, and is it part of the terms or something you have to request? Does it describe the same data, retention and deletion as the privacy policy?
8. Sub-processors
Why it matters: your shortener relies on hosting, database, payment and analytics providers. Each may touch the data, and you should be able to name them.
Ask: is there a named list of sub-processors, and what does each one do?
9. Transfers outside the UK and EU
Why it matters: personal data can leave the UK or EU only with safeguards, such as the UK International Data Transfer Agreement (IDTA) or the EU Standard Contractual Clauses (SCCs).
Ask: where is the data processed, and which safeguards apply if it leaves the UK or EU?
10. Controller and processor roles
Why it matters: for data collected through your links and forms, you, the person sharing the links, are usually the controller, and the shortener is usually your processor. The legal basis, the privacy notice and requests from the people who click are yours to handle, with the tool's help.
Ask: does the policy set out these roles, and will the provider help with access or erasure requests?
Worked example: Weeny against the checklist
Here is how Weeny answers each question today. The quotes come from our live privacy policy (https://weeny.app/privacy) and DPA (https://weeny.app/dpa), checked on 8 October 2026.
1. Cookies and scripts. Our policy says: "No cookies on short-link clicks: Clicking a Weeny short link does not set a cookie on the visitor’s device." Redirects also load no scripts. The one exception is a password-protected link, which sets a cookie after the visitor enters the password.
2. Click data. Our policy says: "Link and form analytics: When someone clicks a short link, scans a QR code, submits a form, views a form, or views a Teeny Page, we derive analytics fields such as country, region, device, browser, and OS from the request, and we may store referrer and related metadata. Visitor IPs for link clicks, QR scans, form submissions, form views, form sessions, and page views are stored as an HMAC-SHA256 hash and cleared after 90 days. Full user agents on form submissions are also deleted after 90 days. Hashed IPs and full user agents are not returned in dashboard analytics API responses to the browser."
3. IP addresses. For link clicks, QR scans, form submissions, form views, form sessions, and page views, the raw IP may be used once to work out the visitor's location. After that, only a keyed hash (HMAC-SHA256) is stored, and a daily job clears it once the record is 90 days old.
One honest caveat. If you set up a webhook on a form, the webhook receives the visitor's raw IP at the moment of submission, and what happens to it after that is up to you.
4. Retention. Our policy says: "Click stats (counts, dates, country, device, referrer) are kept for as long as your account exists. Visitor IPs for link clicks, QR scans, form submissions, form views, form sessions, and page views are stored as an HMAC-SHA256 hash and cleared after 90 days. Form submission user agents are also deleted after 90 days." In short: lifetime click stats, with visitor IPs for link clicks, QR scans, form submissions, form views, form sessions, and page views hashed and cleared after 90 days.
5 and 6. Ads and sale of data. No cookies or scripts on redirects, no ads, we never sell click data. In the words of our policy: "No sale of click data: We do not sell or rent click or form analytics to advertisers."
7. DPA. A DPA is incorporated into our terms, so you do not need to request one. And our own example shows why item 7 matters: our DPA does not yet repeat the hashing and 90 day wording from the privacy policy. It describes the data as "names, email addresses, IP addresses and related request metadata used for analytics and security, and any other information the Controller chooses to collect via Weeny Forms", and its deletion clause covers the end of the service: "Upon termination of the Service, the Processor shall, at the choice of the Controller, delete or return all Personal Data, unless legal obligations require continued storage." We are bringing the DPA in line with the privacy policy. Until then, rely on the privacy policy for the hashing and deletion detail.
8. Sub-processors. Both documents name them: DigitalOcean (managed PostgreSQL database hosting), AWS (infrastructure and storage), Vercel (hosting and deployment), Stripe (payments), PostHog (product analytics in our app, subject to cookie consent) and DataFast (website analytics on weeny.app).
9. Transfers. Our policy says: "We may process your information using cloud infrastructure outside the UK or EEA. In such cases, we ensure appropriate safeguards are in place (e.g., UK International Data Transfer Agreement or EU Standard Contractual Clauses)."
10. Roles. Weeny is run by JPCoding, a sole trader registered in the UK. JPCoding is the controller for your account data. For the data your links and forms collect, you are the controller and Weeny is your processor, as the DPA sets out. You still need your own legal basis and privacy notice for the people who click your links or fill in your forms.
What about Bitly?
"Is Bitly GDPR compliant?" is a common question. The honest answer is the same as for any tool, including ours: run the checklist. Bitly publishes a DPA as Appendix A to its terms (https://bitly.com/pages/terms-of-service). Its cookie policy (https://bitly.com/pages/cookies) says each click of a Bitly link is tracked using a unique identifier stored in one or more cookies in the visitor's browser. Both checked on 8 October 2026. For a fuller side by side, read our Weeny vs Bitly comparison: https://weeny.app/blog/weeny-vs-bitly
Your part
Whichever tool you choose, a few things stay with you:
- Mention link and form analytics in your own privacy notice, or your client's.
- Decide your legal basis. If it is legitimate interests, write down a short balancing test.
- Keep a copy of the provider's DPA and note when you checked its privacy policy.
- Check again whenever the provider changes its policies.
Try Weeny
Weeny puts short links, forms and link-in-bio pages in one tool, with your own subdomain, no cookies or scripts on redirects, no ads, and no sale of click data. Starter is £6.99 a month or £69.99 a year, with a 7-day trial (card required). If it is not for you, you can request a refund within 30 days of your first payment.
Run this checklist against our policies, then see if Weeny fits how you work: https://weeny.app?utm_source=blog&utm_campaign=gdpr-short-links