The not making sense bit is a consequence of several waves of changes, some of them not really involving standards.<p>The first thing to be added here, I expect, was the handling of the query string.  This was needed to allow non-ASCII things to be submitted via forms; the need for this arose before there was any support for non-ASCII domain names, and likely before there was any real need for non-ascii paths.<p>The issue with forms as they were initially created is that they would submit to some server and the server would then process the query string.  In doing so it would do whatever it did for non-ASCII stuff; there was no standard.  In practice, it would percent-unescape and then treat the bytes as being in whatever encoding the server developer happened to default to.  Typically this was the encoding the web page was in as well.  Yes, this is totally busted if your form has a name field and the name being input is not representable in ISO-8859-1 or whatever you authored your page in, but this was an incredibly common way to handle non-ASCII in the 90s.  This all predates my involvement in browsers, so I&#x27;m not sure which is the chicken and which is the egg here, but the upshot was that browsers started sending the query string in the page encoding (with various hacks that were not interoperable for a while in cases when the text was not representable in that encoding) and servers started depending on this behavior.  Then the accept-charset attribute got added to &lt;form&gt; to allow overriding the default behavior for people who wanted something else.  The behavior of form submission via the query string in terms of encodings is specified at <a href="https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;forms.html#picking-an-encoding-for-the-form" rel="nofollow">https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;forms.html#picking-an...</a> and <a href="https:&#x2F;&#x2F;url.spec.whatwg.org&#x2F;#concept-urlencoded-serializer" rel="nofollow">https:&#x2F;&#x2F;url.spec.whatwg.org&#x2F;#concept-urlencoded-serializer</a> and <a href="https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;forms.html#url-encoded-form-data" rel="nofollow">https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;forms.html#url-encode...</a> which bridges them.<p>I think the next step was url paths; for those browsers were inconsistent for a bit about whether UTF-8 was used or whether the page encoding was used, but eventually all aligned on UTF-8, and this got standardized in the HTML spec as well, I&#x27;m fairly certain.<p>And for hostnames, punycode encoding was more or less a must for doing DNS resolution.  And at that point that ended up getting sent on the wire as well.  <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc2616#section-14.23" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc2616#section-14.23</a> defines the Host header, which is presumably what we&#x27;re talking about here, since that&#x27;s the only way the hostname is sent to the server (note that this is NOT part of the same byte string as the path and query).  Following the breadcrumbs for that through <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc2396" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc2396</a> it all talks about this header sending the DNS name, which is why I assume browsers settled on sending punycode here.  %-encoding in hostnames wasn&#x27;t really a thing for a while, I think; e.g. Firefox didn&#x27;t even support it until about 6 months ago.