Hash character settings

Be sure to carefully think through your objectives and choose the right character set from the start.

If you created the following example links in base62:

http://short.com/hash1 -> http://long-url1.com/path1

http://short.com/Hash1 -> http://long-url2.com/path2

and hash character set is changed back to base3X (case-insensitive), both "Hash1" and "hash1" will be seen as identical and both will redirect to http://long-url1.com/path1

That situation can be fixed by switching back to "case-on" base62, but any other custom keywords with capital letter variations ("hASH1","HaSh1" etc.) that were working with "case-off" will break.

Pros and cons of base3X vs. base62

Capital letter custom hashes can be created in both base32 and base36, but those redirects will ignore capital letters and see only one destination (the lower case version). This means you can share many different variations and all visitors will end up at the same place (eg. shortdomain.com/Clickhere same as shortdomain.com/clickherE). It also means that visitors can generate their own accidental capital letter variations and still redirect correctly. Nice in situations where visitors are manually entering short links, but the trade-off for more user-friendly character sets is a longer URL due to fewer possible combinations.

Base62 short links must be used exactly as created because shortdomain.com/Clickhere and shortdomain.com/clickherE are interpreted as separate and unique URLs. So case-sensitive is less forgiving if humans are doing any transcribing, but you gain more URLs per hash count.

Total possible short links vs. length of hash