What actually makes a URL shortener privacy-first

What most shorteners actually store

Every click through a shortener carries an IP address and a User-Agent header, because HTTP requires them. The question that matters is what happens to them after the redirect fires. Many shorteners' answer is: they get logged, in full, indefinitely — a raw IP and a raw User-Agent string sitting in a database row, tied to a timestamp and a link. That's not a bug exactly, it's just the default outcome of not deciding to do anything else.

A raw IP address is personal data under GDPR — it's specifically named in Recital 30 as an example of an online identifier. A full User-Agent string is often precise enough to narrow down to a small set of individuals when combined with other data. Neither is anonymous just because it looks like a technical artifact rather than a name.

The design choice: derive, then discard

The alternative isn't "don't collect anything" — an analytics product needs to answer "how many clicks, from where, on what kind of device." The alternative is to compute the low-entropy answer to that question at write time and then discard the high-entropy raw input that produced it, rather than keeping both.

Concretely, at redirect time:

• The raw IP is run through HMAC-SHA256 with a secret server-side key, and the current hour is folded into the input before hashing. The stored value is the hash, not the IP — and because the hour is part of the input, the same visitor produces a differenthash each hour, which limits how far a stored hash can be used to link someone's activity across time even by someone with access to the hashes themselves. The raw IP is never written to disk.
• The full User-Agent string is parsed into coarse categories — device class, browser family, OS family — and only the categories are kept. "Mobile · Safari · iOS" is stored; the exact User-Agent string, which can be specific enough to fingerprint a device, is not.
• The full referring URL is reduced to its host — twitter.com, not the full URL with whatever query parameters or path it carried, some of which can contain session tokens or search terms.

None of the raw values are recoverable afterward, because they were never stored in the first place — this isn't a retention policy that deletes them later, it's that they never exist as a row on disk to begin with.

Honoring the signal a visitor already sent

Browsers can send Do Not Track or Global Privacy Control headers, and a lot of infrastructure quietly ignores them. When either is present, ShortLynx still counts the click for aggregate volume — a link's total click count stays accurate — but records none of the categorized dimensions above for that click. The signal costs nothing to honor and it's the one direct, unambiguous statement of intent a visitor can send without a cookie banner in the way.

k-anonymity: the part that protects the report, not just the row

Hashing individual clicks well doesn't automatically make an aggregate reportsafe. A campaign with 12 total clicks, broken down by country, can still show "1 click from Iceland" — a number small enough to functionally identify a specific person if the audience is known. Every breakdown — in the dashboard, the API, and CSV exports alike — folds any value seen fewer than 10 times into an "Other" bucket instead of showing it directly. The report stays useful; a single row just can't single someone out.

What this doesn't solve

This whole approach lives entirely in one redirect pipeline. It has nothing to say about how you store recipient email addresses if you're running user-attributed links, what your account data retention looks like, whether you have a lawful basis for the outreach campaign itself, or any of the other genuinely hard parts of actual compliance work. Reducing what a link-tracking tool retains is one input to that picture, not the whole picture — see the disclaimer at the top of this page.