Typically, when I see //, it's usualy following some protocol prefix like http: or ftp:. I have never seen it placed anywhere else. For example,


is a typical URL.

However, I found the following two syntaxes to yield different versions of the same site,



I would have thought that // anywhere other than the protocol specification would be invalid. To my surprise, I was wrong. What is it about the ending //that yeilds a different version of the same site?


Somebody at that site must have caught wind of the other because both links now land on the same page.

  • 9
    If I had to guess, all you're doing is seeing the same site twice but the one with the extra / on the end is breaking the CSS or whatever kids these days use to format their websites with. :)
    – Mark Allen
    Aug 23 '12 at 20:16
  • webmasters.stackexchange.com might be a better fit for this question. Aug 23 '12 at 20:23
  • 1
    @MehperC.Palavuzlar In retrospect, yes. But at the time of the question, I thought the scope was somewhat wider than what it is. Aug 23 '12 at 20:25
  • @MarkAllen Well its interesting to note that using /// or //// at the end of the URL resulted the same site as / where // did result in something different. Aug 24 '12 at 14:01
  • Meanwhile the double backslash (\\) is commonly seen in Windows's Uniform Naming Convention, e.g., \\HostName[@Port]\SharedFolder\Resource
    – William C
    Aug 24 '12 at 14:34

The leading // is part of the URL syntax. The inventor of the world wide web has apologized for that mistake.

Really, if you think about it, it doesn’t need the double-slash. I could have designed it not to have the double-slash. -- Sir Tim Berners-Lee, inventor of the world wide web

As for the trailing //, it's really not a double slash. The first slash separates the host name from the path. The last slash is the path. A web server can, if it wants to, treat a path of / different from an empty path, and apparently weather.com's does. As for whether this is by accident or intentional, you'd have to ask them about that.

  • That makes complete since, because you can configure a web server to look for an index other than just the web root! My hat's off to you good sir. Aug 23 '12 at 20:18
  • Are you saying http://example.com can be treated differently from http://example.com/ ? I didn't think that was the case with the first slash. Aug 24 '12 at 8:41
  • 1
    @DisgruntledGoat You could, yes, using some .htaccess rules. But you probably shouldn't.
    – Matthew
    Aug 24 '12 at 9:53
  • 1
    You can't treat http://example.com different from http://example.com/ in a web server, since they both have an empty path. You could treat them differently in a browser. Aug 24 '12 at 11:12
  • 3
    neverminding the host header, zero or one slashes translates to the same http request: GET / HTTP/1.1: tools.ietf.org/html/rfc2616.html#section-3.2.3 Aug 24 '12 at 12:17

More recently, it could be argued that the double slash does have a role. Google recommend (to avoid accidentally calling insecure content from a secure page, for example) omitting the protocol from embedded resources (stylesheets, js etc), like this

<script src="//www.google.com/js/gweb/analytics/autotrack.js"></script>

So it is now apparent that such a protocol-less URL is a fully qualified URL and not a relative URL (which would begin with a single slash).


To actually answer the question, the original specification gave the protocol http: (or possibly ftp:, gopher:, mailto:, news:, telnet:, wais:, file: or prospero:) then a // to indicate that the Uniform Resource Locator (URL) syntax was being used, then the host (optionally prefixed with user:password@) then address proper starting with another /. This was proposed in RFC 1738.

As the internet evolved, http: became the dominant protocol so browsers now assume that a prefix of http:// should be added if it isn't there.

  • 3
    Your answer would seem to indicate that something other than URL could have been used with the protocol at one point, and would have used something other than // to indicate it was in use... Is that so?
    – Izkata
    Aug 24 '12 at 3:15
  • 3
    @Izkata In the late 80s and 90s, when the internet was starting up, there were several different formats suggested for various items. URLs were/are a subset of URNs (see RFC 3305) and these can have varying formats, e.g. isbn:1-23-456789-12-3. In practics, the http: defines that the rest will be a URL. RFCs are just proposals and often allow for extensions which never materialize. At one point, Tim Berners-Lee said that the // was for a 'subnet' (eg. http:/govnet/whitehouse.gov). This idea was never used, but '//' remains as so much code now expects and checks for it.
    – StarNamer
    Aug 24 '12 at 12:06
  • 1
    @Izkata: you would probably not see a non-URL URN used with a communications protocol; that's what the // is for. It indicates that the protocol is being used to access a (possibly remote) network location where a resource is to be found. There are plenty of other URN's that have other data parts and don't use // (your browser probably recognizes "mailto:", for example). See: en.wikipedia.org/wiki/URI_scheme
    – KutuluMike
    Aug 24 '12 at 15:23
  • @MichaelEdenfield Well, that's what I'm wondering now. Was there ever a point where it was intended to be used differently - something different that could communicate through the same protocol. As a crude example, could the intention at one time have been for http://www.google.com/ and http:%/ to both be valid, and // indicate a hostname while something else like %/ indicate an IP address?
    – Izkata
    Aug 24 '12 at 15:46
  • 1
    I don't think so. At least I've never seen any draft documents/examples/etc that have alternative heirarchy scheme for URLs. My impression has always been that TBL just wanted something to make it obvious that a URL pointed to an actual resource (and not arbitrary data), and using // made things look sufficiently-file-like. Every other style of URN I've ever seen has no special prefix in it's data part. Some protocols do allow that (I think telnet and gopher, e.g.) but I've never seen anything like that for http(s).
    – KutuluMike
    Aug 24 '12 at 15:53

I'd like to add to David's accepted answer:

Despite the apology of inventor of the web I think the double-slash syntax served an important purpose: to visually stand out. Double-slashes allowed easy visual distinction of URLs in a text without hyperlinks. When you saw double slashes you immediately thought it could be entered in a browser window, similar to how you thought a text containing @ could be used to send an email. It was especially crucial during the transition phase to web where protocols of that era (ftp, telnet, gopher) had their own weird notion to represent server addresses or resource paths, rarely both. Most of the problems associated with double-slashes would still exist, because double slashes are the least cryptical part of a URL, think about port numbers, percent encoding and case-sensitivity. But having a URL like http:something.com could easily be confused with my example here:something.com. Look at http:// on the other hand, how it shines like a diamond. Double-slashes have been an important part of Web symbolism and I believe it accelerated it's adoption rate too, even if it was unintentional.

They also might have made AmigaOS's job easier to differentiate between file names and URLs since AmigaOS used the file path syntax volume:path/to/destination. :)

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