Binary-to-text encoding is to represent binary data as characters.

Hex dump of binary files seem also do the same for reading binary files.

Are they related or different things?


I think taking a look at some of the examples of binary-to-text encoding may help clear this up. These are pulled from your Wikipedia link.

For example, let's start with the "Percent Encoding". You've likely seen this one in URLs, with all sorts of things like "%20" showing up (that represents a space). Transmitting raw binary data (and even some things like spaces) is not allowed as part of a URL, but from time to time it would be nice to have a way to tell a computer on the other end about some "out of band" binary information. In this way, "Percent Encoding" acts simply as a very inefficient tunnel for binary data - harmless because it is text, unless the other end is specifically looking for binary data. On the other hand, reading the encoding looks something like a hex dump and is not impossible to decode by hand.

Or consider Uuencoding or MIME's usage of Base64. Here the goal is not only to tunnel binary data over text, but to do it in such a way that the transfer is fairly efficient. However, it is much harder to read it and make sense of it.

Note here that in both cases, the web forms a common backdrop behind the technology usage. I don't believe that this an accident, as web technologies were very much designed for interchange, and text (for some definition of text) forms a sort of lowest common denominator.

Now compare that with a hex dump. The whole point of a hex dump is to convey binary information to you - not a computer - with ease. In both cases it is the transfer of binary information to a specific audience through the allowed means, so there is some commonality. But for binary-to-text it is usually to a computer and via ASCII, and for a hex dump it is to a person via hexadecimal. That being said, a hex dump certainly could be used as a binary-to-text method in a pinch.

Side note: I think the inclusion of S-Records (etc) in the list is interesting. I suppose they could be considered binary-to-text encodings, but strictly speaking they can convey not only a specific binary file, but rather act as a binary patch - which is a broader goal; the binary-to-text encoding is probably more accurately a part of the S-Record. If I were trying to learn about binary-to-text encodings, I feel like these might muddy the waters a bit.


A binary-to-text encoding is something designed for efficient data transfer through a "text only" medium rather than for human readability. A hex dump is something designed for human readability and not efficiency.

If you convert binary into hex digits, you're looking at a maximum of 4 bits of binary data per character. This means the size of the text will be at least twice as large as the original binary data.

This assumes there's no spaces or anything between the hex numbers. For a hexdump there are spaces between them that reduces efficiency further. For example, you might have a space between each pair of digits, an address or offset on the left, a new line character on the right, etc.

For better "binary to text" you'd use a larger base to reduce the number of characters. For example, if you can use 64 characters you might convert the binary into base64 (and not base16), and in that case you get 6 bits of binary data into each character, and the size of text will be 1.3333 times as large as the binary data (instead of 2 times as large or worse).

The best case (assuming characters are fixed size) is to use as many of the characters as you can; which depends on where the text is going (e.g. if it's going across a "7-bit ASCII" serial port you might be able to use 128 characters, if it's going in XML you might not be able to use a bunch of control characters and be left with maybe 95 characters, if it needs to be case insensitive you might be down to about 50 characters, etc).


A hex dump will have characters 0..9 and A..F, one byte becomes a pair of characters.

binary to text has characters 0..9, A..Z and a..z and punctuation etc. Text will often include simple compression eg 3 bytes can be split into 4 characters. But more complex compression eg LZMA can be used as well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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