Actually, no. From RFC 1738, Section 3.10:<p><pre><code>   A file URL takes the form:
   
       file:&#x2F;&#x2F;&lt;host&gt;&#x2F;&lt;path&gt;
   
   where &lt;host&gt; is the fully qualified domain name of the system on
   which the &lt;path&gt; is accessible, and &lt;path&gt; is a hierarchical
   directory path of the form &lt;directory&gt;&#x2F;&lt;directory&gt;&#x2F;...&#x2F;&lt;name&gt;.
</code></pre>
And then in Section 5 (the BNF):<p><pre><code>   ... elements may be preceded
   with &lt;n&gt;* to designate n or more repetitions of the following
   element; n defaults to 0.
   
   fileurl        = &quot;file:&#x2F;&#x2F;&quot; [ host | &quot;localhost&quot; ] &quot;&#x2F;&quot; fpath
   
   fpath          = fsegment *[ &quot;&#x2F;&quot; fsegment ]
   fsegment       = *[ uchar | &quot;?&quot; | &quot;:&quot; | &quot;@&quot; | &quot;&amp;&quot; | &quot;=&quot; ]
</code></pre>
So that first slash isn&#x27;t part of the path, and the path starts with a directory name.  The fact that the root directory in a UNIXy environment doesn&#x27;t have a name (or has a zero-length name) is a source of much confusion. (Nobody would accept &quot;file:&#x2F;&#x2F;&#x2F;&#x2F;etc&#x2F;passwd&quot; as a URL, but that&#x27;s how I read the spec.)<p>This is also why Firefox insists that there are five consecutive slashes when encoding a UNC string (a Windows&#x2F;Samba share path, like &quot;\\server\share\path\to\file.txt&quot;) into a URL (e.g.: &quot;file:&#x2F;&#x2F;&#x2F;&#x2F;&#x2F;server&#x2F;share&#x2F;path&#x2F;to&#x2F;file.txt&quot;)<p>And let us not even begin on the fact that file: URLs are specified in an &quot;obsolete&quot; spec, and explicitly allow characters in the path that are disallowed by RFC 3986. I&#x27;m working on fixing that [<a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;draft-ietf-appsawg-file-scheme" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;draft-ietf-appsawg-file-scheme</a>] but it takes time.