What Referrer Does a Short Link Send to the Destination?

You shortened one URL, dropped it into a newsletter, a DM, a Slack channel and a LinkedIn post, and the destination's analytics reported almost all of it as Direct. So you asked the reasonable thing: did the shortener eat my referrer? Does a redirect overwrite it with the short domain? Should the report say flyn.co somewhere?

The answer is specific and it is written down. The Referer header (one r, a 1990s typo that became permanent) is not something your server or your shortener writes. The browser writes it, under a rule called Referrer Policy, and an HTTP redirect is handled by that rule in a way most people guess wrong. Verified on Sep 10, 2026 against the current specifications and browser vendor announcements linked throughout.

Who actually writes the header

In RFC 9110, section 10.1.3, the Referer field lets the client say which resource the request came from: the page that contained the link the visitor followed. The same section tells senders to omit it when the referring resource is sensitive, which is the reasoning behind every default you are about to read. Nothing in the HTTP standard lets the recipient of a request, a shortener included, choose what the next request's Referer says. Your redirect can set a policy header. It cannot forge a source.

What the default policy sends

Every major browser now defaults to strict-origin-when-cross-origin. Per the W3C Referrer Policy specification, that policy produces three outcomes: a same-origin request gets the full URL stripped for use as a referrer, a cross-origin request from a secure page to another secure URL gets only the ASCII serialization of the origin, and a request that downgrades from HTTPS to HTTP gets no referrer at all. In practice, a visitor clicking from a blog post to your site hands you https://blog.example/ and nothing more: no path, no query string, no campaign tags. If referrer data feels thinner than it did in 2018, that is why, and it has nothing to do with redirects.

This is not a vendor quirk you can configure away. All three engines moved to the same stricter default within about a year of each other, and said openly that it would dent server-side analytics. MDN dates the change to a November 2020 specification revision, and notes that the same policy now applies when a page sends no policy at all or sends an invalid one.

Tap to enlarge

What the vendors said they were breaking

Chrome's announcement is unusually blunt about the cost: "only the origin is sent in the Referer header of cross-origin requests", and "server-side logging or analytics that rely on the full referrer URL being available are likely to be impacted by reduced granularity." Mozilla framed Firefox 87 as trimming "path and query information for all cross-origin requests," replacing the older no-referrer-when-downgrade default. WebKit went a step further in March 2020: "All cross-site document.referrers are downgraded to their origin," so client-side scripts see the same trimmed value the header carries.

A page can always be stricter than the default

The default is a floor, not a ceiling. Any page can send a Referrer-Policy header or a meta tag of no-referrer, and any individual link can carry rel="noreferrer", which asks the browser to send nothing. Large platforms do this routinely on user-generated links. That is a decision made on the page where the link lives, long before your short link is involved, and you cannot override it from the redirect. You can check what a page declares with the security headers checker.

Here is the part that settles the argument. The Referrer Policy specification has a dedicated algorithm for redirects, and it does something narrower than people assume: it updates the policy, and it leaves the source alone.

Section 8.2, "Set request's referrer policy on redirect," reads: "Let policy be the result of executing Parse a referrer policy from a Referrer-Policy header on actualResponse. If policy is not the empty string, then set request's referrer policy to policy." That is the whole step. Fetch calls it while running HTTP-redirect fetch, before the redirected request goes out. There is no step that says "set request's referrer to the redirecting URL."

The referrer is derived from the referrer, not from the hop

Section 8.3, "Determine request's referrer," is the other half. When a request already carries a URL as its referrer (which is exactly the state a request is in after the first hop), the algorithm sets referrerSource to that existing referrer, then applies the current policy against the request's current URL. So on the second hop the browser compares the original page's origin with the destination's origin, not with the shortener's. Cross-origin and secure, and the outcome is the same origin-only value the first hop produced.

The redirect owns the policy for the next hop

Here is the case where a plain 302 does change the value, and it falls out of the same two sections. Because 8.2 sets the request's referrer policy from the redirect response, the policy applied on the second hop is the redirector's, not the referring page's. So if the page carrying the link declares a policy looser than the redirect does, say unsafe-url or no-referrer-when-downgrade, the default the browsers above replaced in 2020 and 2021, a direct click would have handed the destination the full URL with its path. Sent through a redirect that carries strict-origin-when-cross-origin, the destination receives the bare origin instead. The same thing happens in a milder form with origin-when-cross-origin: it keeps sending the origin on an HTTPS to HTTP downgrade, where the stricter policy on the redirect drops the referrer altogether. Flyn's redirect carries exactly that header, so Flyn is one of the redirects this applies to, and no HTML is involved anywhere in the chain: the 302 alone did it.

The rule worth memorising is narrower than the one this page used to print. A redirect cannot restore detail that was already stripped, and it cannot forge a source, but it can absolutely loosen what the destination receives. Fetch stores the computed value back onto the request before the first hop leaves, at the point Referrer Policy describes as "Step 8 of the Main fetch algorithm", so by the time the redirect is followed the request's referrer is already a fixed string, and 8.3 takes that string as its referrerSource. What the redirect's policy still decides is how much of that string travels, and whether it travels at all. That is a lever in both directions: it is why a shortener can suppress a referrer with no interstitial at all by answering no-referrer on the 3xx, and equally why one answering unsafe-url can send a referrer the referring page's own policy would have withheld. The only thing no response header can do is substitute a source of the redirector's own choosing. We published the one-way version of this rule, it was wrong, and the next section is the measurement that showed it.

Tap to enlarge

Walk one click through it

A visitor is on https://blog.example/post and taps a link to https://flyn.co/a1B2c3, which points at https://shop.example/item.

1. Request one: browser to flyn.co, with Referer: https://blog.example/. Cross-origin, so the origin only. This is the value Flyn stores on the click.
2. The response: a 302 with a Location header and Referrer-Policy: strict-origin-when-cross-origin. No HTML, no script, nothing that could re-author the referrer.
3. Request two: browser to shop.example, with Referer: https://blog.example/ again. The short domain appears nowhere.

And the corollary that explains your report: if request one arrived with no Referer, request two has none either. A redirect cannot forward a header that was never sent.

This page shipped with a rule that was wrong, and correcting it is the most useful thing on it. The published version said the asymmetry ran one way only: that a redirect could tighten what the destination sees and could never loosen it. The first half of that is right. The second half is not, and our own measurement is what falsified it.

What we measured, and how

On 2026-09-11 we fetched one live short link on each of ten URL shortening services, once each, with a desktop Chrome user agent, and did not follow redirects automatically so that every hop was recorded separately. Only the first hop, the shortener's own response, is attributed to the shortener; headers set by the final destination are not counted. Three of the links were minted by us to a destination we control (tinyurl.com, da.gd, clck.ru). Five were live links found in a Common Crawl sample of real shared URLs (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 public YouTube video. Because a single link could be an outlier, bit.ly was re-checked on six independent live links, and all six returned the identical policy header.

Four of the ten send a policy at all, and two of those send a loose one

Read the second column against the browser default of strict-origin-when-cross-origin. bit.ly answers with unsafe-url, which is the loosest value the specification defines: it sends the referrer the request is carrying in full, and it keeps sending it on an HTTPS to HTTP downgrade where the default sends nothing. buff.ly answers with no-referrer-when-downgrade, the pre-2020 default that all three engines replaced precisely because it was too permissive. Six of the ten send no Referrer-Policy at all, which is not a neutral position either: an absent header leaves the request carrying whatever policy it already had, so those six inherit the referring page's policy rather than setting one.

ow.ly is the odd row. It sends two values in a single header, origin-when-cross-origin, strict-origin-when-cross-origin. The specification's parse step walks the token list and keeps the last valid one, so a browser resolves that to the default. Flyn is the only service in this sample that sends strict-origin-when-cross-origin as its only value, and ow.ly is the only other one that lands on the same policy once the header has been parsed. You can read any page's declared policy the same way with the security headers checker, and any redirect chain with the redirect checker.

Why a loose policy on a redirect really is a loosening

Tap to enlarge

Section 8.2 sets the request's referrer policy from the redirect response, so the policy applied on the hop into the destination is the redirector's. What that policy operates on is the referrer the request is already carrying, and that is the half the old claim got right: if hop one already reduced the value to an origin, nothing on the redirect can put the path back, because Fetch stored the computed string onto the request before hop one left. But cannot restore is not the same as cannot loosen, and there are two cases where the difference is visible.

• The downgrade. A click from a secure page to a destination still on plain HTTP sends no referrer at all under the default policy. unsafe-url has no downgrade rule, so the same click routed through a redirect declaring it hands the destination the referring origin. A referrer that would not have been sent is sent.
• The path that survived hop one. When hop one was same-origin, which is exactly what happens when the short link sits on the same host as the page carrying it, the request arrives at the redirect still holding the full referring URL with its path and query. The hop into the destination is cross-origin, and under the default that value would be trimmed to an origin. Under unsafe-url it is not trimmed at all, so the destination receives the path and the query string. The same applies whenever the referring page declares a loose policy of its own: a stricter redirect would have cut the value down, and a redirect sending unsafe-url does not.

Be precise about the case that is not affected, because it is the common one. An ordinary cross-origin click from a page using the browser default arrives at the shortener already reduced to an origin, and passing it through bit.ly does not turn it back into a full URL. The loosening is real, it is measured, and it lives in the two cases above rather than in every click. Anyone telling you a shortener leaks your full URL on every hop is overstating what this header can do.

What this scan cannot tell you

One link per service, one fetch, one location, one user agent. Header behaviour is a property of the service rather than of the individual link, and the six-link bit.ly re-check supports that, but a single fetch cannot see per-region or per-account variation, and any service can change a header the day after it is measured. Two services we wanted in the set, v.gd and dub.sh, are absent because no live link for either turned up in the sample. da.gd answered a link we minted on it with a 200 and no Location at all, so its row describes a response that never redirected. Above all, this is a header scan and not a browser test: it records what each service declares, and every consequence described above is derived from the specification rather than observed in a browser. Ten services are not the market. Treat the table as ten verified data points with a date attached, not as a league table, and re-run it yourself before quoting it months from now.

The same scan, the cookie column

The same ten responses carried one more finding, and it belongs here with its qualifier attached rather than as a number on its own. Eight of the ten set at least one cookie on the redirect response itself, before any destination was reached; flyn.co and ow.ly set none. That count means very little unbroken, because the eight are not the same kind of thing. At one end, clck.ru sets a Yandex identifier on .clck.ru that expires in 2036, about ten years out, and bit.ly sets _bit on its own domain expiring in about six months. At the other, tinyurl.com and is.gd set only __cf_bm, the HttpOnly Cloudflare bot-management cookie that lasts about thirty minutes and was written by infrastructure rather than by the shortener, and buff.ly sets a one hour click identifier scoped by Path to that one link. Adding a ten year identifier to a thirty minute bot check and reporting "8 of 10" throws away the only distinction a reader needs. The per-service breakdown, and what it means for consent, is in click tracking and cookie consent. As measured on 2026-09-11 the Flyn redirect set no cookie, which matches what the next section reports from our own side of the wire.

A shortener is in a position to state this rather than theorise about it, so here is Flyn's behaviour, field by field, as of Sep 10, 2026.

One 302, one policy header, no HTML in the path

A plain Flyn short link answers with a 302 and a small fixed header set that includes Referrer-Policy: strict-origin-when-cross-origin, X-Content-Type-Options: nosniff and X-Robots-Tag: noindex, nofollow, noarchive. The redirect is also sent uncached: a live check on Sep 10, 2026 returned Cache-Control: private, no-store, so every click reaches the origin and gets counted rather than being served from a CDN. Because the redirect body is empty, there is no document on the short domain for the browser to treat as a referring page. That is the mechanical reason your short domain does not show up in the destination's referral report. The policy header is the one part of the response that can still change what the destination reads. Because the value Flyn sends is the browser default rather than something looser, it can only tighten: it trims a looser referring policy down to an origin, and it never hands over more than the default would have. That is a property of this particular header value, not of redirects in general. Two of the ten services in the scan above send a value that does the opposite.

On the way through, Flyn stores the incoming referrer along with country, city, device, operating system, browser, a hashed IP, any UTM values present on the short URL and a timestamp. No advertising identifier, and as of Sep 10, 2026 the redirect sets no cookie. Hits from crawlers, link-preview fetchers, headless browsers, HTTP libraries, uptime monitors and blank user agents are screened by user agent before anything is counted and reported separately as filtered bot hits. Be clear about which half of that you get for free: how many of your clicks were real is free, and where the real ones came from, the country, device, browser and referrer breakdown, is on Pro. The field list is in the clicks API.

Tap to enlarge

The same-host exception, written into the code

There is one case where a short domain genuinely does arrive as a referrer: when the previous page was also on that domain. A short link whose destination is another short link, or a cloaked link whose frame loads a short URL, produces a same-origin request, and the default policy sends the full URL in that case. Flyn normalises those hops before storing them: if the incoming referrer's host is the same short-link host the visitor is on, the click is recorded as Direct rather than as a referral from itself. The reasoning is in the source comment next to the function: that hop is internal redirect plumbing, not an acquisition source, and surfacing it would displace the real external referrer, which was already lost when the chain passed through the first hop. That same-origin case is also the one place a query string travels in the header: any UTM values or click IDs sitting on the short URL are inside the full URL the browser sends on that hop, which is a consent question rather than a measurement one, and the pixel consent guide is where that argument belongs. If your referrer panel looks emptier than expected, a chain of two short links is the first thing to check with the redirect checker.

This is the table people come looking for. The left column is what Flyn records on the click; the right column is what the destination's analytics receives afterwards. In most rows they are the same value, because the redirect forwards the source it was handed rather than replacing it. The rows where they differ are the interesting ones, including the row where the redirect's own policy trims a full URL down to an origin. A redirect answering unsafe-url would move that row in the opposite direction, which is the correction above; every row here describes a Flyn link.

Tap to enlarge

How to read the two columns

The shortener and the destination usually see the same thing, and when they see nothing, they see nothing for the same reason. Where the two differ on a Flyn link, it is always in the same direction: Flyn never sees less than the destination does, because the only thing strict-origin-when-cross-origin on the redirect can do to a referrer is trim it. Read that as a consequence of the header Flyn sends and not as a law about redirects. Route the same click through a redirect answering unsafe-url and the destination can be handed more than the default would have given it, which is what we measured on bit.ly. The short link is a witness, not a thief: it records the value at the moment of the click, on your own domain, with bot hits screened out, which is more than a referral report gives you.

The rows you should test rather than trust

Two rows move. Webmail providers rewrite and wrap outbound links and set their own referrer policies, so measure your own sender rather than trusting a blanket claim from anyone, including this page. AI assistants are changing quickly, and Flyn classifies those referrals into their own channel on Pro rather than letting them hide in Direct. A few native apps do hand a referrer to the browser tab they launch, which is why the occasional in-app click arrives with a source, so treat the in-app rows as per-app behaviour and test the apps that matter to you rather than assuming a blanket rule. Preview and unfurl bots are a separate subject: they fetch the link without a human, and Flyn counts them in the filtered bucket rather than in your referrers.

Now connect the header to the report, because the report is where the confusion starts. Analytics tools have no "no referrer" channel. They have a default bucket, and it is called Direct.

Tap to enlarge

Direct is a residue, not a channel

In GA4's default channel group, Direct is defined as source exactly matching (direct) and medium being (not set) or (none), while Referral requires a medium of referral, app or link. Read those two rules together and the conclusion is mechanical: a visit with no Referer and no campaign parameters cannot be classified, so it falls into Direct. Direct is not a statement that the visitor typed your URL. It is the absence of evidence, and every channel in the table above that sends nothing ends up pooled there with genuine bookmark traffic.

Direct is not a traffic source. It is the bucket where every click that arrived without a referrer and without a tag goes to be forgotten.

When your short domain does show up as a referral

Three situations put the short domain in the destination's referral report, and all three involve an HTML page rather than a 302: a pixel interstitial, a cloaked link whose frame loads the destination, and any meta refresh or JavaScript bounce you build yourself. If you see your own short domain in the referral list for a plain link, check whether something in the chain is serving a page instead of a redirect: the link inspector shows the status code and the headers that came back.

You cannot legislate the Referer header back into existence. You can make your measurement independent of it. Work through these in order.

Tap to enlarge

The seven steps

1. Tag the destination URL, not the short URL. Query parameters on the destination survive every row of that table because they travel in the Location header, not in Referer. Build them in the UTM builder, then read the full UTM reference for naming discipline.
2. Use one short link per channel. A separate link for the newsletter, the DM and the LinkedIn post gives you a clean first-party count per channel even when every one of them lands in Direct downstream. This is the single highest-value habit in click tracking.
3. Check that your tags survive the hop. Run the link through the UTM preservation checker and confirm the destination receives them; see how a redirect carries a query string for the rules.
4. Mark QR codes separately. A scan never carries a referrer, so a distinct link or a distinct tag per QR code is the only way to separate print from digital.
5. Audit what actually arrived. Paste the landing URLs into the UTM parser before launch, not after.
6. Compare first-party clicks to destination sessions. Your click analytics and the destination's session count will never match exactly; the gap tells you about bots, bounces and pre-fetching, which is what human click counts are for.
7. Keep campaign values out of anything sensitive. Never put a name, an email or an identifier in a UTM value, because that string travels in the URL bar, in your logs and, on a same-origin hop, in the Referer header itself. Flyn's GDPR page covers what a click record holds.

One link per channel beats one link everywhere

If you take one operational habit from this page, take that one. The Referer header is the only part of attribution you do not control, so stop building on it. A newsletter link, an SMS link and a Telegram link that differ only in their slug will out-measure a single clever link every time.

Four mistakes account for most of the cases where a referrer disappears and the shortener gets blamed.

Client-side redirects and extra hops

A meta http-equiv="refresh" page or a JavaScript location assignment is a navigation started by a document, so the referring page becomes that document, not the original source. Build a redirect that way and you have replaced the visitor's source with your own URL. The same goes for stacking shorteners: every extra hop is another chance for a policy to tighten or loosen the value, for a downgrade to drop the header, or for a same-host hop to collapse into Direct, and you inherit whatever policy the shortener in the middle happens to send. Keep chains to one hop.

Downgrades, noreferrer and over-strict policies

If your destination is still served over plain HTTP, the policy removes the referrer and nothing upstream restores it; fix the certificate. If the platform hosting your link adds rel="noreferrer", as many user-generated-content sites do, the browser sends nothing from the start. And if your own site declares no-referrer site-wide, you are erasing the source of your own outbound clicks, including the ones you are trying to measure. Remember too that a rel attribute is a separate switch from the policy header.

Do not take any of this on trust, including from us. The behaviour is observable with tools you already have.

Check one: what the redirect itself answers with

Point curl at any live Flyn link. The command and the output below are verbatim, run on Sep 10, 2026 against a real link on our own account, and the grep is only there to keep the header dump short.

curl -sI https://www.flyn.to/yt-channel | grep -iE 'HTTP/|^location|^referrer-policy|^cache-control|^x-robots-tag'

HTTP/2 302
location: https://www.youtube.com/@flynlinks
cache-control: private, no-store
referrer-policy: strict-origin-when-cross-origin
x-robots-tag: noindex, nofollow, noarchive

A 302, a Location, the policy header, and no body. That is the whole response.

Check two: hand it a referer and follow the hop

Now set a Referer of your own and watch both requests go out. The lines beginning with a greater-than sign are what the client sent; the ones beginning with a less-than sign are what came back.

curl -sL -o /dev/null -v -H 'Referer: https://test.example/page' https://www.flyn.to/yt-channel 2>&1 | grep -E '^(> GET|> Host|> Referer|< HTTP|< location)'

> GET /yt-channel HTTP/2
> Host: www.flyn.to
> Referer: https://test.example/page
< HTTP/2 302
< location: https://www.youtube.com/@flynlinks
> GET /@flynlinks HTTP/2
> Host: www.youtube.com
> Referer: https://test.example/page
< HTTP/2 200

The second request, the one that reaches the destination host, still carries https://test.example/page. The short domain appears in the Host line of hop one and nowhere else. Be precise about what that proves, though: curl is not a browser. It resends the header you gave it and implements no part of Referrer Policy, so this shows that the hop forwards the referer it was handed and never substitutes the redirector, and it says nothing about whether a browser would have sent a path or an origin in the first place. That half is the policy question, and it needs a browser.

Check three: what a real browser sends

Open a test page on one origin, put your short link on it, click it with devtools open on the destination and read the request headers plus document.referrer. Run it again from an email client and from a messaging app on your phone, and you have reproduced the table above with your own stack. The redirect checker and the in-app browser detector cover the cases you cannot easily inspect by hand, and creating a throwaway link takes under a minute on the free plan.

Then stop optimising for a header three browser vendors spent a decade narrowing, and move your attribution onto parameters and per-channel links you own. Flyn stores the referrer that arrives and is honest about the rest: a click with no referring page is Direct, not a guess. See the shorten endpoint and link analytics.

One honest limit: this page does not publish a measured share of Flyn clicks that land in Direct, because that number has not been measured and verified for publication. The mechanism is documented above and every claim about it is sourced; the percentage is not, so it is absent rather than estimated.

This is a technical reference, not legal advice. If you want the detail of what a click record holds, read how Flyn handles click data, and take legal questions to a qualified professional.