Where l.facebook.com Comes From and Why Clicks Land as Direct

What is l.facebook.com?

Facebook rewrites outbound links so every click passes through l.facebook.com, the intermediary hop Meta calls the link shim, before the browser reaches your page. Meta's engineering blog named the tool in 2012 and described it as a way "to warn people about potentially spammy or malicious links." The hostname is a redirect service and nothing else. Request the bare domain and it answers HTTP/2 302 with location: https://www.facebook.com/, checked on 12 September 2026.

Meta still uses it on its own properties. Every outbound link in the footer of developers.facebook.com is shimmed, which makes the format easy to read off a live page rather than a screenshot.

What does an l.facebook.com URL look like?

Two query parameters carry everything. The destination sits percent-encoded in u, and a signature sits in h:

https://l.facebook.com/l.php?u=https%3A%2F%2Fwww.llama.com%2F&h=AUCy45wK_2QEcW5a...

Because the full destination URL is percent-encoded into u, its own query string survives the hop. Any utm_source or utm_campaign you put on a link is still attached when the browser lands.

The h parameter is not a hash of the destination. Fetching the same Meta page twice on 12 September 2026 produced two different h values for the identical llama.com target, which means the signature is bound to the session that rendered the link rather than to the URL. Copy a shimmed link out of Facebook and paste it elsewhere and it does not resolve: both a signed and an unsigned l.php request returned HTTP/2 400 with Facebook's generic "Sorry, something went wrong" page when requested without the originating session.

Meta runs parallel hostnames for its other surfaces, and all of them behave the same way.

Why does Facebook route clicks through a shim at all?

For two reasons Meta states outright, and only one of them costs you anything. The first is malware screening. The second is deliberate referrer restriction.

Meta's 2012 post "A faster, better link shim" describes the redesign that is still in place. Rather than checking a link after the click, "we now check every link on the page before it's sent to the browser," and "if we find a link to be suspicious, we use the old interstitial warning page; otherwise we allow the user through to the link itself." Meta measured the saving at "around a second every time they click an external link."

The referrer half is stated just as plainly, under a heading called Restricting the Referrer: "We still need to let the websites you navigate to know the traffic is from Facebook, but we also want to prevent them from reading the full source url. Otherwise, they could know where on the site you were when you clicked their link." That is not a side effect. It is the design goal.

What does the link shim do to your referrer?

It hands you an origin instead of a URL. Meta's 2012 post says it "taken advantage of a new feature called the meta referrer," which "allows us to specify how much of the source url to share with the external site via the Referer header." The tag is still on the page today. Fetching www.facebook.com on 12 September 2026 returns this in the head:

<meta name="referrer" content="origin-when-crossorigin" id="meta_referrer">

There is a wrinkle in that string. The W3C Referrer Policy specification defines exactly nine valid tokens, and origin-when-crossorigin is not one of them. The spelled-out token is origin-when-cross-origin, with a hyphen between cross and origin. The spec also says "unknown policy values will be ignored," and that "the default referrer policy is strict-origin-when-cross-origin."

Both roads end in the same place for you. If a browser accepts Meta's legacy spelling, cross-origin navigations send the origin only. If a browser rejects it and falls back to the default, cross-origin navigations still send the origin only. Either way the Referer header that arrives at your server is a bare origin such as https://l.facebook.com/, never the post, the group or the profile the click started from.

The one case where you get nothing at all is a protocol downgrade. Under strict-origin-when-cross-origin, a navigation from an HTTPS page to an HTTP destination "would send no Referer header." A site still serving plain HTTP loses the attribution completely.

Why does l.facebook.com traffic land as direct in analytics?

Because the Referer header did not arrive, not because Google mislabels the hostname. This is where most advice about the shim gets it backwards.

Google publishes the list of sources it maps to channels, and l.facebook.com, lm.facebook.com, l.instagram.com and l.messenger.com all appear on it as SOURCE_CATEGORY_SOCIAL. GA4's Organic Social channel matches when the source "matches a regex list of social sites" or the medium is one of social, social-network, social-media and similar. So a click that arrives carrying the shim origin is already classified as Organic Social. There is nothing to fix and no referral exclusion to add.

The Direct channel has a much narrower definition: source exactly matches (direct) and medium is (not set) or (none). Nothing lands there by misclassification. It lands there when the analytics tag has no referrer and no campaign parameters to work with. Three situations produce that:

• A protocol downgrade, where the spec says no Referer is sent at all.
• A handoff out of an in-app browser into the system browser, where the new navigation is not a link click and carries no referrer of its own.
• A copied and pasted link, which arrives with no referrer by definition because nobody clicked anything.

The general shape of this bucket, and what else falls into it, is covered in this explainer on direct traffic.

How do you stop losing the attribution?

Tag the URL before it reaches the composer, because the shim preserves the query string it wraps. The destination is carried percent-encoded inside u, so utm_source=facebook&utm_medium=social&utm_campaign=spring-launch survives the redirect and reaches your analytics intact. Campaign parameters also outrank the referrer in GA4's channel matching, which means a tagged link is classified the same way whether the Referer header shows up or not. The naming conventions that keep this consistent across networks are worked through in this guide to UTM parameters.

Link wrapping is not a Facebook quirk. X does the same thing with its own shortener, rewriting every posted URL into a t.co link with its own effects on what your server sees. Meta's crawler side has the same split personality: the preview card is built by a separate fetch from the facebookexternalhit crawler long before any human clicks the shim.

Two sets of numbers are worth keeping separate. Impressions, reach and clicks recorded on the Facebook side come from Meta's own APIs, which is what a tool like adaptlypost surfaces under social media analytics. The session that lands on your site is a different record kept by your own analytics, and the link shim sits in the gap between them. Tagging the URL is what closes it.

Frequently asked questions

Should I add l.facebook.com to my referral exclusion list?

No. Google's published source list already maps l.facebook.com to SOURCE_CATEGORY_SOCIAL, so GA4 reports those sessions as Organic Social rather than as a generic referral. Excluding the hostname removes the referrer and pushes those sessions into Direct, which is the outcome most people are trying to avoid.

Can I see which Facebook post a click came from?

Not from the referrer. Meta's stated design goal is to "prevent them from reading the full source url," and the header that reaches your server is an origin such as https://l.facebook.com/ with no path. A utm_content value that is unique per post is the only way to tell two posts apart.

Why does a pasted l.facebook.com link not work?

Because the h parameter is a signature tied to the session that generated the link, not to the destination. Requesting l.php outside that session returned HTTP/2 400 and Facebook's generic error page in both a signed and an unsigned test on 12 September 2026.

What is the difference between l.facebook.com and lm.facebook.com?

The surface that generated the click. lm.facebook.com is the mobile web counterpart, and the bare hostname redirects to https://m.facebook.com/?_rdr where l.facebook.com redirects to https://www.facebook.com/. Google files both as social sources.

Does the link shim strip my UTM parameters?

No. The destination URL is percent-encoded whole into the u parameter, query string included, so campaign tags arrive with the visitor. Parameters go missing when a link is retyped or shortened by hand before posting, not at the shim.

Does every Facebook link go through the shim?

Meta's 2012 description says links are screened before the page is sent to the browser, and that suspicious links get an interstitial warning page while everything else passes through to the link itself. Meta publishes no rule for which links are rewritten to l.php and which are not, so treat the hop as present by default and tag accordingly.

Why does Facebook route a click through l.facebook.com instead of linking straight to my page?

Meta gives two reasons for the hop: screening links for malware before a click ever reaches the browser, and limiting how much of the source URL leaves Facebook. The malware check runs on the page itself, ahead of any click. The referrer limit is just as deliberate, laid out under Meta's own heading, Restricting the Referrer.

Does checking every link for malware make clicks slower?

Meta says the opposite happened. The 2012 redesign that checks links before they reach the browser saved about a second on every external click compared with the old post-click system. Suspicious links still get the interstitial warning page, but everything else passes straight through to the destination.

Why do two people get different h values for the same shimmed link?

The h parameter is not a hash of the destination URL, it is a signature tied to the browser session that rendered the link. Fetching the same Meta page twice on 12 September 2026 produced two different h values for the identical llama.com target, which shows the value depends on the session rather than the link. A copied link fails outside that session even when its h value is fresh.

How can I find the real destination inside an l.facebook.com link before clicking it?

The destination sits percent-encoded in the URL's u parameter, along with the rest of the query string, including any utm_source or utm_campaign tags. Decoding that parameter shows the exact page the link points to without going through the shim. The h parameter next to it is only a session signature and carries no information about the destination.