Upon inspecting Twitter's URL shortening service http://t.co, I noticed that, instead of redirecting to the goal URL using a Location HTTP header and a 3xx HTTP status code, it redirects using the following HTML (formatted for better readability):

  <meta name="referrer" content="always">
    <META http-equiv="refresh" content="0;URL=[URL]">
<script>window.opener = null; location.replace("[URL]")</script>

where [URL] would contain the actual goal URL. To be clear: this is the complete HTML content, not just an HTML fragment.

A large/popular service like http://t.co will surely have good reasons to choose this strategy over HTTP header redirection, but I can't think of any.

What are the benefits of choosing this redirection strategy over HTTP header redirection?

I just realized that it might be the <meta name="referrer" content="always"> tag. Will this keep a possibly existing Referer request header intact, perhaps?


4 Answers 4


As your edit suggests, the client-side redirect in conjunction with the referrer meta tag better ensures that the Referrer header is sent. Though it's not exactly the same problem, a quick search on the referrer meta tag offers suggests the purpose is SEO-ish in nature.

SEOs have long used referrer data for a number of beneficial purposes. Oftentimes, people will link back or check out the site sending traffic when they see the referrer in their analytics data. (moz.com)

Twitter doesn't care as much that you link back. But, they do want to ensure they get credit with site owners as a major traffic source / marketing tool.

The client-side redirect helps keeps Twitter in business.

If clarification is needed: A referrer meta tag on the initial page isn't sufficient. Because of the URL shortening and redirection, as well as the possibility of tweets being copied or posted in other places, the intermediate page is essential to ensure Twitter receives every ounce of credit it can possibly slurp up.

  • This sounds very plausible. Thanks. I initially had a brain fart about the workings of this meta tag of course, when I suggested it would perhaps pass the originating Referer header through transparently. Meta referrer tags don't work like that, nor would it be likely that Twitter would want this anyway. Your answer sounds like the actual motivation behind being able to use the meta tag. And, as of yet the equivalent HTTP header Referrer-Policy doesn't appear to be widely supported yet. Commented Mar 7, 2017 at 19:29

Actual benefits:

JavaScript redirects can be useful for redirecting mobile devices from a desktop version of a page to its mobile version, or vice versa for desktops. The server will only know the User-Agent, not the actual width of the screen. You could for instance swap between two version when the screen gets tilted from portrait to landscape and vice versa.

JavaScript would allow very temporary redirects. It doesn't matter if the response gets cached in the browser, the script can still execute differently. The destination can change more often than the page/response from the server does. You could for instance redirect to a randomly chosen page each time the page is accessed, or perhaps add a timestamp in a query string when redirecting.

Developer laziness:

Both JavaScript redirects and meta refreshes can be implemented without having access to the HTTP headers. This can be useful for poorly implemented server side scripts: you can redirect a page after the headers have already been sent, and you don't need to change large parts of code.

Totally pointless:

Both JavaScript redirects and meta refreshes will allow a delay before the redirect. If you want to show a message that the user will barely have time to read, this is a good solution.

  • Those sound like very plausible benefits indeed, thanks! But I suspect svidgen's answer is a bit more to the point in the context of t.co's redirecting mechanism, particularly since the HTML/Javascript I've shown appears to be all that there is. However, would you mind elaborating a bit more about your second point? I don't think I completely understand that one. Thanks again. Commented Mar 7, 2017 at 18:37

The main benefit I can think is it would allow browser caching to be used, which on the scale of twitter, would be substantial. Other thought is maybe twitter logging/stats application they use needs it.

  • Sounds interesting, but would you be willing to elaborate on your suggestions? I don't immediately see how it would offload Twitter's cache (if that is what you are suggesting) and/or how it could benefit a logging/stats application. Thanks. Commented Mar 6, 2017 at 18:52

Normally server side redirects are preferred.

One scenario of client side redirect is localstorage/sessionstorage. If you need to copy some data from server to localstorage client side redirect is the way to go.

The disadvantage of using client side redirect is browser history can contain the useless redirect step. This can be mitigated by using window.location.replace(newurl) instead of window.location = newurl or meta tags.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.