What was the design choice here? Why are URLs designed to not be case-sensitive?

For example: When I type "gaming.stackexchange.com", it will take me to Arqade.SE. If I type "GaminG.StackExchangE.CoM", it'll take me to the same place.

I understand that there are some counter-examples to this, as some have pointed out below.

  • 1
    I'm not sure where to put this question. Would UX.SE be a better fit? – yuritsuki Mar 14 '13 at 9:17
  • I wish URLs were even more forgiving than merely having case-insensitive host names. I would like to see often-confused characters being interchangeable in UIs, including URLS, for example: (1) / and \ ; (2) 1 and I and l (so also i and L); (3) 0 and O (so also o); ... the list goes on. – Adrian Pronk Mar 16 '13 at 4:13

RFC 1035 section 2.3.3 states that DNS names are case-insensitive. This means that the host part (and only the host part) of URLs is case-insensitive.

I don't know the precise thinking behind that decision, but the standard was written in 1987 at a time when systems with limited support for mixed-case character sets were still relatively commonplace.

| improve this answer | |

I can come up with two reasons without them necessarily having anything to do with the original decision.

  • ease of use
  • elimination of ambiguity

Imagine having to remember difference between:

google Google GOogle GooGle GoogLe GooglE (....)

It's rather impractical if Host.com means something entirely different than host.com. A DNS name is supposed to be a label, and having special characters or making a difference between capital and lower letters only complicates that without serving any practical purpose.

| improve this answer | |

Possible reasons:

  • Security: There's only 37 valid characters in DNS names*. Lowercase alpha characters have bit 6 set, so a resolver library or DNS server can immediately and relatively simply sanitize its input by ANDing with binary 0100 0000 and throwing out anything that isn't ASCII 45, 48 through 57 (numbers), or 65 through 90 (letters). Once you run into a dot you're done. No need to figure out what is and ignore whitespace, tokenize, or do any of the other lovely and buffer-overrun-minefield stuff that's involved in parsing text. Having an explicit limit of 63 (?) characters on hostnames helps this too.

  • DNS as a whole is massive and needs to work quickly. I'm sure it helps speed up indexing and lookups through DNS databases for a DNS name to contain a limited number of characters. Probably a similar thing could be said for size. Given the capabilities of computers at the time DNS was invented I'm sure cutting things down to the "bare minimum" was seen as necessary.

  • I do believe around the time DNS was invented there were actually computers and terminals in use that could not display lowercase characters (I'm thinking Apple II here but I'm sure some old mainframes of the time had equally old terminals attached).

*You've seen unicode domain names before? Those are internationalized domain names - an extension built on top of this. They really internally consist of "xn--" and then a Punycode-encoded string using the standard set of DNS characters, and are rendered as Unicode by a compliant browser.

| improve this answer | |

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