Binary-to-text encoding
A binary-to-text encoding is a data encoding scheme that represents binary data as plain text. Generally, the binary data consists of a sequence of arbitrary 8-bit byte values and the text is restricted to the printable character codes of commonly-used character encodings such as ASCII. In general, arbitrary binary data contains values that are not printable character codes, so software designed to only handle text fails to process such data. Encoding binary data as text allows information that is not inherently stored as text to be processed by software that otherwise cannot process arbitrary binary data. The software cannot interpret the information, but it can perform useful operations on the data such as transmit and store.
PGP documentation uses the term "ASCII armor" for binary-to-text encoding when referring to Base64.
Conceptually, binary-to-text encoding differs from numeric representation for a numeric base. For example, decimal is a scheme for representing a value as base-10, but it is not a binary-to-text encoding. A binary-to-text encoding could be devised that uses decimal representation for encoded data, but such a system would use only 10 values of a 4-bit encoded sequence, leaving 6 values unused. A more efficient encoding would use all 16 values. This is Base16 which uses hexadecimal for encoding each 4-bit sequence. Notably, because 16 is a power of two, Base16 and hexadecimal are indistinguishable in practice even though they differ conceptually.
Escape encodings such as percent-encoding and quoted-printable also allow for representing arbitrary binary data as text, but in a significantly different way. A binary-to-text encoding involves encoding an entire input sequence whereas an escape encoding allows for embedding binary data in data that is already and inherently text.
Use
Transmitting binary data as text
A binary-to-text encoding enables transmitting data on a communication channel that does not allow arbitrary binary data or is not 8-bit clean. The encoding enables transmitting binary data over a communications protocol that is designed to carry human-readable text. Often such a protocol only supports 7-bit character values, and may require line breaks at certain maximum intervals, and may not maintain whitespace. Thus, only the 94 ASCII#ASCII [printable characters |printable ASCII characters] are safe to use to convey data.The ASCII text-encoding standard uses 7 bits to encode characters. With this it is possible to encode 128 unique values to represent the alphabetic, numeric, and punctuation characters commonly used in English, plus a selection of non-printable control characters. For example, the capital letter A is represented as 65, the numeral 2 is 50, the right curly brace '''
Encoding plain text
Binary-to-text encoding methods are also used as a mechanism for encoding plain text. Some systems have a more limited character set they can handle; not only are they not 8-bit clean, some cannot even handle every printable ASCII character. Other systems have limits on the number of characters that may appear between line breaks, such as the "1000 characters per line" limit of some Simple Mail Transfer Protocol software, as allowed by. Still others add headers or trailers to the text. A few poorly-regarded but still-used protocols use in-band signaling, causing confusion if specific patterns appear in the message. The best-known is the string "From " at the beginning of a line, used to separate mail messages in the mbox file format.By using a binary-to-text encoding on messages that are already plain text, then decoding on the other end, one can make such systems appear to be completely transparent. This is sometimes referred to as 'ASCII armoring'. For example, the ViewState component of ASP.NET uses base64 encoding to safely transmit text via HTTP POST, in order to avoid delimiter collision.
Examples
The table below describes notable binary-to-text encodings. The efficiency listed is the ratio between the number of bits in the input and the number of bits in the encoded output.| Encoding | Efficiency | Programming language implementations | Comments |
| Ascii85 | 80% | ,,,,,,,, | There exist several variants of this encoding, Base85, btoa, etc. |
| Base16 | 50% | Most languages | As it's based on hexadecimal, there are variants for upper, lower or either case |
| Base32 | 62.5% | ,,,,, | |
| Base36 | ~64% | bash, C, C++, C#, Java, Perl, PHP, Python, Visual Basic, Swift, many others | Uses only numerals and lowercase letters. Commonly used by URL redirection systems like TinyURL or SnipURL/Snipr as compact alphanumeric identifiers. |
| Base45 | ~67% | , | Defined in IETF Specification RFC 9285 for including binary data compactly in a QR code. |
| Base56 | — | ,, | Like Base58 but further excludes characters 1 and lowercase-O in order to minimise the risk of fraud and human-error. |
| Base58 | ~73% | ,,,, | Like Base64 but excludes non-alphanumeric characters and pairs of characters that often look ambiguous when rendered: zero and capital-O, and capital-I and lowercase-L. Base58 is used to represent bitcoin addresses. For SegWit, it was replaced by Bech32. |
| Base62 | ~74% | , | Like Base64 but contains only alphanumeric characters. |
| Base64 | 75% | ,,,,,, many others | An early and still-popular encoding, first specified as part of in 1987 |
| Base85 | 80% | ,, | Revised version of Ascii85. |
| Base91 | 81% | Constant width variant | |
| basE91 | 81% | , | Variable width variant |
| Base94 | 82% | ,, | |
| Base122 | 87.5% | ,,,,, | |
| BaseXML | 83.5% | ||
| Bech32 | 62.5% + at least 8 chars | C, C++, JavaScript, Go, Python, Haskell, Ruby, Rust | Specification. Used in Bitcoin and the Lightning Network. The data portion is encoded like Base32 with the possibility to check and correct up to 6 mistyped characters using the 6-character BCH code at the end, which also checks/corrects the Human Readable Part. The Bech32m variant has a subtle change that makes it more resilient to changes in length. |
| BinHex | 75% | ,, | MacOS Classic |
| Intel HEX | ≲50% | , | Typically used to program EPROM, NOR flash memory chips |
| MIME | See Quoted-printable and Base64 | See Quoted-printable and Base64 | Encoding container for e-mail-like formatting |
| S-record | 49.6% | , | Typically used to program EPROM, NOR flash memory chips. 49.6% assumes 255 binary bytes per record. |
| Tektronix hex | Typically used to program EPROM, NOR flash memory chips. | ||
| , | TxMS compresses binary data into a readable text format using Binary-to-Text encoding and allows reversible conversion back to hexadecimal. | ||
| Uuencoding | ~60% | Perl,,,,, probably many others | An early encoding developed in 1980 for Unix-to-Unix Copy. Largely replaced by MIME and yEnc |
| Xxencoding | ~75% | , | Proposed as replacement for Uuencoding to avoid character set translation problems between ASCII and the EBCDIC systems that could corrupt Uuencoded data |
| z85 | 80% | ,,,,,,, and others | Specifies a subset of ASCII similar to Ascii85, omitting a few characters that may cause program bugs. The format conforms to . |
| 33% | C, | "A Convention for Human-readable 128-bit Keys". A series of small English words is easier for humans to read, remember, and type in than decimal or other binary-to-text encoding systems. Each 64-bit number is mapped to six short words, of one to four characters each, from a public 2048-word dictionary. |
Some older and today uncommon formats include BOO, BTOA, and USR encoding.
Base64 maps sequences of 6 bits to printable characters. Since there are more than 26 = 64 printable characters, this is possible. A given sequence of bytes is translated by viewing it as a stream of bits, breaking this stream into chunks of 6 bits and generating the sequence of corresponding characters. The different encodings differ in the mapping between sequences of bits and characters and in how the resulting text is formatted.
Some encodings use four bits instead of six, mapping all possible sequences of 4 bits onto the 16 standard hexadecimal digits. Using 4 bits per encoded character leads to a 50% longer output than base64, but simplifies encoding and decoding—expanding each byte in the source independently to two encoded bytes is simpler than base64's expanding 3 source bytes to 4 encoded bytes.
Out of PETSCII's first 192 codes, 164 have visible representations when quoted: 5, 17–20 and 28–31, 32–90, 91–127, 129, 133–140, 144–159, and 160–192. This theoretically permits encodings, such as base128, between PETSCII-speaking machines.