Well, it&#x27;s clear to see why people are lead astray. In this case, RFC  3986, which defines what a URI actually is, itself actually proposes a regex[0]. It even claims, and I quote, &#x27;the &quot;first-match-wins&quot; algorithm is identical to the &quot;greedy&quot; disambiguation method used by POSIX regular expressions&#x27;. Of course, it doesn&#x27;t actually <i>validate</i> anything... it just performs rudimentary field extraction. Trying to do anything beyond that with regex is madness.<p>The ABNF grammar is fairly simple though and, I think, free of ambiguities. I&#x27;ve had luck converting it straight in to PEG form. It&#x27;s not a trivial or wholly useful endeavour though, and, if you do so, remember to check the errata. For HTTP you&#x27;ll also have to add in the changes from RFC 7230[1].<p>Oh, and of course, none of this validates DNS names, their labels, etc. for length, the &quot;LDH rule&quot;, or the public suffix list[2], or IP addresses to check whether they have publicly routable prefixes.<p>Bottom line is, if you want to validate a URL, the best thing to do, much like e-mail, is to just try and GET it.<p>[0] <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc3986#appendix-B" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc3986#appendix-B</a><p>[1] <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc7230#section-2.7.1" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc7230#section-2.7.1</a><p>[2] <a href="https:&#x2F;&#x2F;publicsuffix.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;publicsuffix.org&#x2F;</a>