Protocol Relative URLs, Why to Use Them, and Common Pitfalls

I’m building a tool to replace my job at work. The idea is that it builds and strings together emails and various types of landing pages to create marketing campaigns. In the process of testing this app I hit a snag. Sometimes the files this app generates live on SSL secured servers, other times they don’t, and don’t get me started on the various combinations of protocol and subdomains that could wreak havoc on links. In the end I was finding that links were broken, styles wouldn’t show, and mixed content warnings were everywhere. It was time to implement protocol relative URLs.

What are they?

A protocol relative URL is just a URL without the scheme. For example // is a protocol relative URL. These types of URLs were meant to be hit by a browser only. The point is that a browser can fetch a resource from whatever protocol the site is telling it to use. So if you’re on an HTTPS site but the links and references on the page are hardcoded as HTTP you’ve got problems.

How to use them

It’s simple. Just leave off the protocol like this


No more mixed content warnings and you can be sure that any URL you put inside an src or href will reliably be pulled by the browser.

But watch out for the pitfalls!

There are a few things that could trip you up in implementing protocol relative URLs. First off, some email clients (Outlook especially, as usual) won’t try to use HTTP or HTTPS as the protocol. Instead they’ll use the file:// protocol and assume the resource you’re referring to is on the local machine. But it won’t be. So don’t use these in emails.

You have to be sure that the server you’re requesting from is capable of serving content over both HTTP and HTTPS. If not you might end up fetching content from an unsecured or nonexistent server port.

IE6 does not know how to handle this. If you care about supporting Internet Explorer 6 then you shouldn’t use these.

IE7-8 support protocol relative URLs but they’ll end up fetching the resource twice. Once from HTTP and once over HTTPS. This can slow things down a bit but the way I see things it’s not much of a problem for anyone except the person using IE7-8 and if you’re using IE you’ve got more important things to worry about.

Web design, Web development

« Logic Dictates You're Not That Profound or Intelligent Introducing Wreditor the In-Browser Text Editor »