Take the 2-minute tour ×

I have a stylesheet that loads images from an external domain and I need it to load from https:// from secure order pages and http:// from other pages, based on the current URL. I found that starting the URL with a double slash inherits the current protocol. Do all browsers support this technique?

html ex:

<img src="//cdn.domain.com/logo.png" />

css ex:

.class { background: url(//cdn.domain.com/logo.png); }
share|improve this question
does this slow down the site??? –  TheBlackBenzKid Oct 4 '11 at 17:53
there's no reason this should have any impact on performance, except in the cases that Meder listed below in her answer. –  Rob Volk Jan 10 '12 at 1:05
Looks like I was on to something. A few months ago, Google Developers started using this convention on their Hosted Javascript libraries page developers.google.com/speed/libraries/devguide –  Rob Volk Dec 20 '12 at 17:16
What if such a HTML file is loaded locally (opened directly with the browser)? Looks like Firefox (28 in this case) then does not load the remote resource. Makes sense, because then HTTP is not the parent protocol. But that would be a disadvantage, in my opinion. –  Jan-Philip Gehrcke Mar 19 at 23:53

6 Answers 6

up vote 42 down vote accepted

If the browser supports RFC 1808 Section 4, RFC 2396 Section 5.2, or RFC 3986 Section 5.2, then it will indeed use the page URL's scheme for references that begin with "//".

share|improve this answer
is this supported on all major browsers? (IE7, IE8, FF, Chrome, Safari) –  Rob Volk Jan 12 '11 at 23:11
Considering that the first RFC to describe it, RFC 1808, was written 15 years ago, and URL references are key to website functionality, I think it is safe to say that pretty much all major browsers do support it by now. But the only way to know for sure is to simply try it yourself and see what happens. –  Remy Lebeau Jan 12 '11 at 23:29
This question was linked from someone asking a similar question, and I found it in RFC 1630 the year before (stated differently, but still allowing the format in question). It could well have been in one form or other of the document that used to be at ftp://info.cern.ch/pub/www/doc/http-spec.txt starting in 1991, should anyone have an archive copy. –  Jon Hanna Aug 27 '12 at 23:45

When used on a link or @import, IE7/IE8 will download the file twice per http://paulirish.com/2010/the-protocol-relative-url/

share|improve this answer
Fixed in IE9, FWIW. –  EricLaw Jan 11 '11 at 20:31
HAHAHAHAHAHA. As always it doesn't work right on older IEs. Oh, my! –  Diego Nunes May 16 '13 at 6:15
@EricLaw is that fixed in IE9 regardless of rendering mode or only in Standards Mode and still broken in Quirks Mode? –  scunliffe Sep 4 '13 at 12:54
I'm almost positive that this was fixed in all modes in the lookahead scanner. Have you seen otherwise somewhere? –  EricLaw Sep 4 '13 at 16:10

One downside occurs if your URLs are viewed outside the context of a web page. For example, an email message sitting in an email client (say, Outlook) effectively has no URL, and when you're viewing a message containing a protocol-relative URL, there is no obvious protocol context at all (the message itself is independent of the protocol used to fetch it, whether it's POP3, IMAP, Exchange, uucp or whatever) so the URL has no protocol to be relative to. I've not investigated compatibility with email clients to see what they do when presented with a missing protocol handler - I'm guessing that most will take a guess at http. Apple Mail refuses to let you enter a URL without a protocol. It's analogous to the way that relative URLs do not work in email because of a similarly missing context.

Similar problems could occur in other non-HTTP contexts such as in tweets, SMS messages, Word documents etc.

The more general explanation is that anonymous protocol URLs cannot work in isolation; there must be a relevant context. In a typical web page it's thus fine to pull in a script library that way, but any external links should always specify a protocol. I did try one simple test: //stackoverflow.com maps to file:///stackoverflow.com in all browsers I tried it in, so they really don't work by themselves.

share|improve this answer
This is a really good point, I was actually thinking about this as I fell asleep last night. Another issue is that the https or http version may not actually be available, you can't always assume that it is. –  Wesley Murch Oct 15 '12 at 15:44
Outside of a browser you're on your own, so to speak. There's no saying if the email or other client knows about javascript or css etc. So this is pretty much a moot point about relative urls? –  chris Jan 28 '13 at 23:06
Not a moot point. Many e-mail clients support JS and browsers certainly can when loading from file://. It is a minor usecase, but when it comes up it is important. –  Jun-Dai Bates-Kobashigawa Jul 23 at 18:05
I do wish there were a way to specify use http unless the current url is https, in which case use https, rather than specifying use the same protocol that the current pages was loaded with, which is effectively what // is. –  Jun-Dai Bates-Kobashigawa Jul 23 at 18:06
If you specify an e.g. <base href="https://www.google.com">, you can view the content outside the web-side. either <img src="//www.google.com/images/srpr/logo11w.png"> or <img src="images/srpr/logo11w.png"> –  zig Nov 26 at 14:13

The reason could be to provide portable web pages. If the outer page is not transported encrypted (http), why should the linked scripts be encrypted? This seems to be an unnecessary performance loss. In case, the outer page is securely transported encrypted (https), then the linked content should be encrypted, too. If the page is encrypted, the linked content not, IE seems to issue a Mixed Content warning. The reason is that an attacker can manipulate the scripts on the way. See http://ie.microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1 for a longer discussion.

The HTTPS Everywhere campaign from the EFF suggests to use https whenever possible. We have the server capacity these days to serve web pages always encrypted.

share|improve this answer

It seems to be a pretty common technique now. There is no downside, it only helps to unify the protocol for all assets on the page so should be used wherever possible.

share|improve this answer

Just for completeness. This was mentioned in another thread:

'The two forward slashes are a common shorthand for whatever protocol is being used right'

if (plain http environment) {
use 'http://example.com/my-resource.js'
} else {
    use 'https://example.com/my-resource.js'

Please check the full thread.

share|improve this answer

Your Answer


