# Looking at hash output – is Base64 encoding in any way better than HEX encoding?

I was wondering why most "normal/unsafe" crypto hashes like SHA-256, SHA-512, Whirlpool, RipeMD-160, MD5, etc. are HEX encoded.

But most "secure" crypto hashes (KDF' ) like bcrypt and scrypt are Base64 encoded. Why?

somewhere I heared that Base64 shortend the string for like 20%. Isn't that extremely bad for password hashed during iterations and makes them less collision resistent?

And if Base64 is really for some reason more secure, then why does Argon2 output HEX encoding?

• 'Isn't that extreamly bad for password hashed during iterations and makes them less collision resistent'; actually, these hashes never do hex/base64 encoding of internal hashes; instead, internal hashes stay represented as bitstrings; the hex/base64 encoding is done only on the final output (and is there mostly because external entities can't handle arbitrary bitstrings that well) – poncho Jul 28 '17 at 15:17
• but when you iterate the hash you take the output hash ( so a b64 or HEX ) value and input it like a normal string into the hashing algo . And reverse the process . Have I misunderstood something ? – Richard R. Matthews Jul 28 '17 at 15:29
• 'you take the output hash ( so a b64 or HEX ) value'; no, the output of the hash may be a 32 byte string, where each byte is a value between 0 and 255. When we display the hash, then we convert it into something a bit more friendly (b64 or hex), but we don't bother if we're just resubmitting it to the hash function... – poncho Jul 28 '17 at 15:32
• @RichardR.Matthews Just for example, English speakers call their mother "mother", Chinese speakers call their mother "妈妈". "妈妈"(2 characters) is much shorter than "mother"(6 characters), but the meaning of the word "妈妈" isn't unclear than "mother", because these two words are the representation of the same concept. – DDoSolitary Jul 28 '17 at 15:41
• you are more likely to see a b64 encoded password hash in a database because the databases are unlikely to accept non ASCII data, and b64 is the most common option that takes the least space – Richie Frame Jul 29 '17 at 1:13

The algorithms themselves just output binary (i.e. bytes) if you read their specifications. It's the implementation in API's and applications that output the hexadecimals and/or base64.

Sometimes there are also ad hoc standards / common practice that specifies a certain output format. This is for instance the case for the output of the bcrypt password hashing algorithm. In that case it's not just the hash that is displayed but also the type of algorithm, number of iterations and if course salt.

Base64 is more efficient than hex, while hex is easier for humans to digest. The value of the bytes as well as the amount of bytes are just easier to see in hex; the amount of stored bytes is for instance simply half of the displayed hex digits. However for textual formats or indeed larger hash values base64 may be chosen for its efficiency (~33% overhead for base64 vs 100% for hex).

The command line utilities md5sum, sha1sum and their successors have always kept to outputting hex; it's to be expected that hex is therefore more likely to be output by applications that want to remain compatible.

Note that I've changed the case of "Base64" and "HEX" in this answer to lowercase to be compatible with RFC 4648: The Base16, Base32, and Base64 Data Encodings which tries to standardize the encodings. It only uses the uppercase variant in the title. "Hex" is an abbreviation, not an acronym, so all uppercase does not make sense.

• Certain kinds of hashes are as likely to be validated by human eyeballs as by machines, while others are intended to be compared solely by machines. If a hash will be processed solely by machines, base64 or base85 would likely be a more efficient choice than hex, but some humans may be more able to look at two hex strings and say whether they "seem" identical than would be possible with base64 [if someone replaced a file with a malicious one chosen so that the first 10%, last 10%, and middle 10% of the hex hash matched even though the rest were random garbage, some people might not notice... – supercat Jul 28 '17 at 23:11
• ...but if people who receive a file randomly pick part of the hex signature to validate, phony files would likely get caught at by at least some users, who could then sound the alarm for everyone else.] – supercat Jul 28 '17 at 23:12
• Also worth noting, that if you are putting encoded values into urls, HEX is url-safe, whereas base64 is not - because it uses / and + characters. You can get url-safe versions of base64 which substitute / with _ and + with -. – guysherman Jul 29 '17 at 17:40
• Right, as specified here. – Maarten Bodewes Jul 29 '17 at 17:42
• It's also easier for programmers to debug crypto code when the "correct" answers are in hex, which corresponds directly to the byte array in question. – chrylis -on strike- Jul 30 '17 at 0:47

Using Base64/HEX has nothing to do with security of a hash algorithm.

Base64 and HEX are ways to represent binary data, which is the actual output of a hash algorithm.

Base64 is shorter simple because it uses a larger charset than HEX. (64 characters vs 16 characters)

Besides, algorithms like SHA-256 and SHA-512 are only "unsafe" when used for password hashing(or similar scenarios). In fact, bcrypt/scrypt/PBKDF2 are simply based on these normal algorithms, but make use of some techniques (salt, many iterations with MAC, …), to construct a algorithm that is secure for password hashing.

• As this answer says, B64 or hex are purely display conventions for the same underlying bit patterns. – JesseM Jul 28 '17 at 23:14