Safari seems to be the only browser that differently handles URL's that have three slashes after the scheme.

For example typing https:///google.com in the address bar results in the URL being converted to https://google.com by all browsers I tried (Edge, Firefox, Opera, Tor), excepting for Safari, which converts the URL to https://localhost/google.com.

The conversion also happens when receiving a HTTP redirect (301 or 302) with a "malformed" URL, but doesn't happen when clicking on a link, in that case Safari is consistent with the other browsers.

Does somebody know why is that? And who's correct - Safari inserting localhost, or the other browsers stripping out the third slash?

  • 4
    Where are you finding URLs for webpages with three slashes?
    – benwiggy
    Commented Feb 16, 2022 at 11:15
  • @benwiggy I stumbled upon a buggy web app that was sending redirects to urls with three slashes, and coincidently I was using mobile safari at that time, otherwise the behaviour would've gone unnoticed.
    – Cristik
    Commented Feb 16, 2022 at 11:19
  • You are facing this only when typed directly in the address bar, right? For me (as per the URL specs), the anchor in your question correctly leads to https://google.com. What happens in the address bar is not specced though, so nobody is wrong.
    – Kaiido
    Commented Feb 17, 2022 at 2:37
  • @Kaiido the behaviour happens when directly typing and when receiving a redirect (301/302) from a server. Indeed, clicking on a link has the same behaviour on Safari as on the other browsers.
    – Cristik
    Commented Feb 17, 2022 at 5:46
  • Ah then this is a Safari bug. Per the Fetch specs they should parse the `Location` header, and this parser does ignore several / after protocol://, just like they do with <a href="url">. You may want to add an issue to their tracker. If it helps, I made a repro-case here.
    – Kaiido
    Commented Feb 17, 2022 at 6:09

3 Answers 3


What happens when the text is entered in the address bar of the browser is not tied by any specs yet, so for this situation there is no "wrong" or "correct" behavior.

However, for redirects sent by the server in response to a fetch request, the Fetch standards rule, and these standards(§8.2 - "follow") ask that the `Location` header in the response be parsed through the URL standards URL-parser algorithm.

This algorithm when it will encounter the third / in the special authority ignore slashes state will emit a validation error, but won't leave this step until all subsequent / are found (and thus ignored).

So the result of parsing an input such as https:///////example.com should be

protocol: "https:"
host: "example.com"
path: "/"

I.E, the multiple / characters after https: are ignored.

And even Safari agrees on that in other places, like in HTML's <a href>, as can be seen from the links in OP.

That they don't follow this rule for fetch redirects is a bug, and as such, you may want to report it to their bug-tracker.


@AlvarPaalberg's answer gives an earlier view

There are later RFCs that I think add to this.

The one I found is RFC7230 defining the http protocol. This includes

A sender MUST NOT generate an "http" URI with an empty host identifier. A recipient that processes such a URI reference MUST reject it as invalid.

Also RFC3986

If the URI scheme defines a default for host, then that default applies when the host subcomponent is undefined or when the registered name is empty (zero length). For example, the "file" URI scheme is defined so that no authority, an empty host, and "localhost" all mean the end-user's machine, whereas the "http" scheme considers a missing authority or empty host invalid.

From that I think all the browsers are incorrect. They should be rejecting the URL as invalid. Now browsers in general have never liked reporting errors for invalid html or anything else so they decide what they think the user typed and use that instead.

Safari has chosen a different view to others. (It has used the rule for the file: scheme - which I guess is due to Safari developers being more integrated withe the OS developers than is the case for other browsers. macOS system APIs us file URLs for most file operations)

  • 2
    Why would the protocol -- which governs how a browser should communicate with a server -- dictate how the UI/UX -- the interaction between browser and user -- works?
    – Polygnome
    Commented Feb 16, 2022 at 17:31
  • 1
    Becaus RFC7230 says at the top "This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) scheme" and the slashes are part of the scheme.
    – mmmmmm
    Commented Feb 16, 2022 at 17:34
  • 2
    Yes, and? That is the protocol the browser uses to talk to other programs. The browser should adhere to it when doing that. But the interaction with the user happens on a different OSI level. Hell, there are many web clients out there which completely hide the URI from the user and you can't even type any in. You assume the address bar of the browser must be an URI, that is definitely wrong. In chrome, can even type in math equations there and get a result, or a google query, or wikipedia query.
    – Polygnome
    Commented Feb 16, 2022 at 17:41
  • 1
    The RFC simply doesn't apply to that field. As long as the browser correctly uses the protocol behind the curtain, there is no RFC violation. Assuming a technical specification is good UX is bad, that is why most browsers have an added layer of abstraction on top of it.
    – Polygnome
    Commented Feb 16, 2022 at 17:42

One can try to give answer to the question why? but not who is correct?

RFC 1738 - Uniform Resource Locators (URL):

The file URL scheme is used to designate files accessible on a particular host computer. This scheme, unlike most other URL schemes, does not designate a resource that is universally accessible over the Internet.

A file URL takes the form:


/../ As a special case, can be the string "localhost" or the empty string; this is interpreted as `the machine from which the URL is being interpreted'.

So it appears that Safari considers three slashes as file URL scheme special case (empty string) and replaces empty string between second and third slash with 'localhost'. Other browsers consider it as user entered one slash too much and actually want to access internet resource so they 'autocorrect' it.

  • If that's the case, seems it's a bug in Safari, as the scheme is https, not file, in order for Safari to consider the url as a file url.
    – Cristik
    Commented Feb 16, 2022 at 9:08
  • @Cristik - from another hand, there is no internet resource URL scheme with three slashes. So one can claim that this is bug if I enter three slashes and are taken to the internet by my browser. Shouldn't error to be raised? file:// is request to local file, http:// is request to file somewhere (including local filesystem) using HTTP protocol. Three slashes are interpreted as request to access local filesystem. I don't pretend to be expert in this area and I have not read all the RFC-s so my interpretation is as good as anybody elses. Commented Feb 16, 2022 at 10:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .