The most sexy browsers screw your analytics

Chrome and Safari fuck with the HTTP_REFERERNow that IE is quite unusable due to the lack of websites that support its non-standard rendering, and the current FireFox version suffers from various maladies, more and more users switch to browsers that are supposed to comply to Web standards, such as Chrome, Safari, or Opera.

Those sexy user agents execute client sided scripts in lightning speed, making surfers addicted to nifty rounded corners very very happy. Of course they come with massive memory leaks, but surfers who shut down their browser every once in a while won’t notice such geeky details.

Why is that bad news for Internet marketers? Because Chrome and Safari screw your analytics. Your stats are useless with regard to bookmarkers and type-in traffic. Your referrer stats lack all hits from Chrome/Safari users who have opened your landing page in a new tab or window.

Google’s Chrome and Apple’s Safari do not provide an HTTP_REFERER. (The typo is standardized, too.)

This bug was reported in September 2008. It’s not yet fixed. Not even in beta versions.

Guess from which (optional) HTTP header line your preferred stats tool compiles the search terms to create all the cool keyword statistics? Yup, that’s the HTTP_REFERER’s query string when the visitor came from a search result page (SERP). Especially on SERPs many users open links in new tabs. That means with every searcher switching to a sexy browser your keyword analysis becomes more useless.

That’s not only an analytics issue. Many sites provide sensible functionality based on the referrer (the Web page a user came from), for example default search terms for site-search facilities gathered from SERP-referrers. Many sites evaluate the HTTP_REFERER to prevent themselves from hotlinking, so their users can’t view the content they’ve paid for when they open a link in a new tab or window.

Passing a blank HTTP_REFERER when this information is available to the user agent is plain evil. Of course lots of so-called Internet security apps do this by default, but just because others do evil that doesn’t mean a top-notch Web browser like Safari or Chrome can get away with crap like this for months and years to come.

Please nudge the developers!

Here you go. Post in this thread why you want them to fix this bug asap. Tell the developers that you can’t live with screwed analytics, and that your site’s users rely on reliable HTTP_REFERERs. Even if you don’t run a website yourself, tell them that your favorite porn site bothers you with countless error messages instead of delivering smut, just because WebKit browsers are buggy.

You can test whether your browser passes the HTTP_REFERER or not: Go to this Google SERP. On the link to this post chose “Open link in new tab” (or window) in the context menu (right click over the link). Scroll down.

Your browser passed this HTTP_REFERER: None

Share/bookmark this: del.icio.usGooglema.gnoliaMixxNetscaperedditSphinnSquidooStumbleUponYahoo MyWeb
Subscribe to      Entries Entries      Comments Comments      All Comments All Comments

27 Comments to "The most sexy browsers screw your analytics"

  1. Lea on 13 November, 2009  #link

    Umm, sorry, but Safari does pass referer - it is my everyday browser and I would have noticed if it didn’t but just to be sure I just checked my access log for my dev box and yep, referers for my traffic right there :)
    No idea about Chrome.

    [Lea, try open the link in a new tab or window via the context menu.]

  2. Andy Gale on 13 November, 2009  #link

    I think if you read the spec you will find out the HTTP_REFERER header is optional and doesn’t need to be provided.

    [Added the link to the spec. Optional or not, most user agents do it just right. Call it best practice, quasi standard, or whatever … it’s expected behavior so it has to be provided.]

  3. Andy Gale on 13 November, 2009  #link

    “SHOULD” in RFCs does *absolutely* not mean must. So these browsers are doing nothing wrong.

    I also must say, editing people’s responses to your posts before you allow them to be published is a little rich isn’t it?

  4. Sebastian on 13 November, 2009  #link

    Andy, adding a link doesn’t change your message. Since I encourage relevant linking in my blog’s comments, you could have done it yourself.

    Of course should != must, I didn’t say that. However, these browsers do it wrong. Not wrong in the sense of standard compliance, just wrong because passing referrers is what everybody expects from a browser. Also, a bugfix is on their to-do list for a year now.

  5. Lea on 13 November, 2009  #link

    Yep, I just did that and Safari (OSX - Version 3.1.2 (5525.20.1)) gives a referer when the page is opened in a tab.

  6. Sebastian on 14 November, 2009  #link

    Lea, for example Safari (WIN - 4.0.3 (531.9.1)) doesn’t. Safari (WIN - 4.0.4 (531.21.10)) doesn’t.

  7. […] The most sexy browsers screw your analytics – was from everyone’s favourite mystery man Sebastian X. It seems that both Chrome AND Safari aren’t passing along referrer stirngs… which as U might imagine, can be a nightmare for your analytics (especially as adoption of Chrome rises). Spread the word and help Seb fight the good fight wontcha? […]

  8. Rob on 17 November, 2009  #link

    The version of Chrome I downloaded from their site (not a developer version) passes referer - you can test it by clicking through to this site:
    What is My Referer.

    [I followed your instructions and showed a blank referrer when I opened the link via context menu in a new tab. By the way, I’ve changed your link, I don’t link out to sales pitches - see my comment policy.]

  9. kaveo on 17 November, 2009  #link

    cmd click (or middle button click) — referer is there
    right-click open in new tab (window) — no referer

    safari 4 mac os

  10. Jacob Rastad on 18 November, 2009  #link

    I tried a couple of things with Chrome.

    When I open a link in a new tab by clicking on the scroll wheel or hold ctrl while clicking on the link, the referrer is passed along. However if I right-click and choose open in a new tab it doesn’t get passed along.

    I agree with Sebastian, even though they don’t have to pass it along to follow standards, there is no reason why not to do it!

  11. Andrew Nattan on 18 November, 2009  #link

    It’s pretty amazing that such an oversight’s managed to get through Google’s quality control. I mean, surely they’d design their browser to be compatible with their analytics software?

  12. Rob on 18 November, 2009  #link

    @kaveo @jacob:
    Well I never - good knowledge.

    Maybe it’s something to do with the way Chome works (creating new processes for each browser tab)? Strange that it’s not consistent.

    I don’t really understand enough about software development, so maybe someone wants to crack the source code open and have a look at what’s going on?

  13. Jacob Rastad on 18 November, 2009  #link

    Could very well be that, but as you say it’s strange that it’s not consistent.

  14. Sebastian on 18 November, 2009  #link

    Rob & Jacob, this bug is pretty well described: Chrome Bug #1935. Please understand that fixing a bug can take some time. I’d just be glad when they’d prioritize this particular bug a level higher, if it’s not possible to assign a developer right now.

  15. Rami on 22 November, 2009  #link

    Hopefully not many people using the open in new tab feature, I have done a test now
    Chrome and Firefox do not show the referral source when you open a page in new tab
    IE8 has no problem, it is working fine.

    Thanks for creating some buzz around this bug

  16. […] de recherche) sont transmises par votre navigateur au moyen de la variable http_referer. Cependant, comme lu sur ce site, les navigateurs réputés les plus rapides, à savoir Chrome et Safari, ne transmettent pas cette […]

  17. davidtan on 10 December, 2009  #link

    It’s really weird why middle-click and right-click new tab can give different referrer.

  18. anonymous on 27 December, 2009  #link

    Claiming it’s a bug to not send a referrer is wrong.

    I’m sorry that it upsets your analysis software, but privacy is more important than having some better tuned sale stats.

    I prefer to not have referrer activated.
    For example, when you click on an unsubscribe link from your within your webbased email client, it would show to the possible spammers that you use gmail for example.
    That’s not something you want them to know.

    It should be an option in the browser, and off by default.
    We already have session cookies to track where we come from. Use those.

  19. Sebastian on 28 December, 2009  #link

    Don’t be such an ignorant privacy nazi. IOW, that’s bullshit. You can’t use session cookies to track 3rd party referrers.

    Sending an HTTP_REFERER is the default behavior in all browsers, and that’s the right thing to do.

    When you don’t want to send an HTTP_REFERER for a particular click, then use PrefBar or a similar tool.

    User agents should offer such an option, for example “Open link w/o footprints” or so. Chrome’s “Open link in incognito window” is a good start.

  20. Aaron Davidson on 22 January, 2010  #link

    A client pointed out a bug on their site with Chrome today.
    I thought it was to do with setting persistent cookies with javascript, but it turned out to be down to no referrer.
    I came across this blog and want to share something of greater concern. After thorough testing I conclude that:
    a) Chrome does support the referrer - though not when opened in a new tab/window (bug#1935)
    b) but not when the referrer was a Google site
    It seems they don’t want you to use referral info from Google and as they control their browser, they can stop it.
    I never understood why Google created a browser, still don’t, but this hints on the sinister.

  21. Vineet Dwivedi on 23 February, 2010  #link

    Oh my God!

    And all the time we were thinking people are typing our name in browsers and coming. Direct hit to our site is unusually high..I think this is the main reason.

  22. Mykola Stryebkov on 9 March, 2010  #link

    @Aaron Davidson
    you’re not quite right: on my Mac Chrome shows different behavior in case of opening a link in a new tab from context menu and opening a new tab by cmd click.

    In the first case Chrom really doesn’t send referer, but in second - does. And this behavior doesn’t depend on source referer. I’ve checked twice :-)

  23. Sebastian on 25 May, 2010  #link

    Here’s Danny Sullivan’s take on The Death Of Web Analytics?

    My plain summary: Fucking with the HTTP_REFERER puts the Web’s economy at risk. If a page is soooo private, by all means link out in a way that not a single user agent passes an HTTP_REFERER to the link’s destination. User agents must not suppress the referrer in general, but really should come with an easy procedure for users who want to follow a link without traces in referrer logs and such.

  24. Doc Crandall on 13 July, 2010  #link

    Humor me. What if I don’t want a website tracking where I’ve come from?

  25. Rob on 19 July, 2010  #link

    @Doc Crandall:
    If you just want to block Google Analytics, I found some methods over here:

    If you want to block all websites and analytics systems from seeing your entry route to a site, I’ve written about disabling your ‘referer’ here:

    (The post was targeted at people doing a particular task, but it works for anyone who wants the privacy that comes with hiding the referrer string.)

  26. Arpit on 11 November, 2010  #link

    I’ve created browser extension for Chrome and Safari to block http referrer information.

    Get from here:

    Feedback welcome!

  27. Sebastian on 23 May, 2011  #link

    Here’s another de-referrer: test, go to

Leave a reply

[If you don't do the math, or the answer is wrong, you'd better have saved your comment before hitting submit. Here is why.]

Be nice and feel free to link out when a link adds value to your comment. More in my comment policy.