 <p>Reversibly encoding the hash doesn't impact collision rate... Unless your encoding causes some loss of data (then it isn't reversible any more).</p> <p>Base64 and other <a href="http://en.wikipedia.org/wiki/Binary-to-text_encoding" rel="nofollow">binary-to-text encoding schemes</a> are all reversible. Your first output is the hexadecimal (or base16) representation, which is 50% efficient. Base64 achieves 75% efficiency, meaning it cuts the 40-character hex representation to 28 characters.</p> <p>The most efficient binary encoding scheme is <a href="http://en.wikipedia.org/wiki/YEnc" rel="nofollow">yEnc</a>, which achieves 98% efficiency, meaning a 100 byte long input will be roughly 102 bytes when encoded with yEnc. This is where the real problem arises for you: SHA-1 outputs are 160 bits (20 bytes) long. If you achieve 200% character-byte efficiency by using every 2-byte UTF16 character, you're still looking at <strong>10 characters</strong>. You can't achieve this, because 2-byte values from U+D7FF to U+E000 are not valid UTF16 characters. Those byte values are reserved as prefixes for higher-plane characters.</p> <p>Even if you find such a hyper-efficient<sup>1</sup> encoding scheme using unicode, you can't really use those as URLs. <a href="http://www.faqs.org/rfcs/rfc1738.html" rel="nofollow">Unicode characters are forbidden from URLs</a> and to be standards compliant, you should use % encodings for your URLs. Many browsers will automatically convert them, so you may find this acceptable, but many of the characters you would regularly use would not be human readable and many more would appear to be in different languages.</p> <p>At this point, if you really need <em>short</em> URLs, you should reconsider using a hash value and instead implement your own identity service (e.g. assign every page or resource an incremental ID, which is admittedly hard to scale) or utilizing another <a href="http://en.wikipedia.org/wiki/URL_shortening" rel="nofollow">link-shortening service</a>.</p> <p><sup>1</sup>: This not possible from a bit standpoint. Unicode could achieve a higher character-to-bit ratio, but the unicode characters themselves are represented by multiple bytes. The % encodings for UTF8, which most browsers use as the default for unrecognized encodings, get messy quickly.</p>