Introduction
Before macOS, before OS X, before even PowerPC, Macintosh files traveled over email and early internet as BinHex 4.0. The format packed both the data fork and resource fork into a single 7-bit-safe ASCII stream, using RLE compression and a custom 6-bit alphabet. This tool encodes and decodes BinHex 4.0 in your browser, showing the RLE compression step and the 6-bit stream as it builds. Paste text to encode, or paste a BinHex block (including the header line) to decode. Everything runs client-side.
What this tool does
- Encode text to BinHex 4.0 format with RLE compression, 6-bit alphabet encoding, and the standard header and colon delimiters
- Decode BinHex 4.0 streams back to the original bytes, automatically stripping the header line, colon delimiters, and whitespace
- Apply RLE compression where runs of 4 or more identical bytes are replaced with byte + 0x90 + count, and literal 0x90 bytes are escaped as 0x90 0x00
- Show the RLE-compressed byte stream and the 6-bit BinHex alphabet output as intermediate steps
- Wrap encoded output at 64 characters per line, matching the conventional BinHex line width
- Run entirely client-side: input and output never leave your browser
How this tool works
The tool implements BinHex 4.0 in three stages. First, RLE compression: the input bytes are scanned for runs of 4 or more identical values. A run of N identical bytes (where N is between 4 and 255) is encoded as the byte value, followed by 0x90 (the RLE marker), followed by the count N. A literal 0x90 byte in the input is escaped as 0x90 0x00 to distinguish it from a marker. Runs of 3 or fewer are passed through uncompressed.
Second, the RLE-compressed bytes are encoded using a 6-bit alphabet of 64 characters: `!"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[\`abcdefhijklmpqr`. Note that this is NOT the standard base64 alphabet. Several characters are missing from the standard ASCII range (notably digits 7, lowercase g, n, o, s, t, u, v, w, x, y, z), which was done to avoid characters that caused problems on certain early mail gateways.
Third, the encoded stream is wrapped at 64 characters per line and framed with the header `(This file must be converted with BinHex 4.0)` and colon delimiters. On decode, the tool reverses all three stages: strip the header and colons, remove whitespace, decode the 6-bit stream back to bytes, then decompress the RLE.
The intermediate steps panel shows the RLE-compressed hex bytes and the first 120 characters of the 6-bit stream, so you can see how compression and encoding interact.
How BinHex 4.0 encoding works
BinHex 4.0 was developed by Yves Lempereur and released in 1985 for the Apple Macintosh. It is documented in RFC 1741, which describes the format as a means of encoding Macintosh files for transport over 7-bit ASCII channels. Apple's own BinHex 4.0 specification defined the RLE compression and 6-bit alphabet used here.
The format was designed to solve a specific Macintosh problem: classic Mac files had two forks (a data fork and a resource fork) plus metadata (file type and creator codes). Standard encodings like uuencoding only handled the data fork. BinHex 4.0 wrapped everything into a single stream that could survive 7-bit email transport.
The RLE compression is simple but effective for files with repeated bytes (common in Mac resource forks, which often contained padding and repeated patterns). The 6-bit encoding maps 3 bytes (24 bits) to 4 characters from the 64-character alphabet, producing the same 33% expansion as base64 but with a different, mail-safe character set.
BinHex 4.0 was superseded by MIME multipart messages with base64 encoding (RFC 2045) once Mac OS X arrived and the resource fork became less common. The `.hqx` file extension identified BinHex files on classic Mac systems. The format is now encountered mainly in archived Mac software, legacy email attachments, and CTF challenges involving retro encoding.
How to use this tool
- Select Encode or Decode mode using the toggle buttons
- For encoding: type or paste text in the input field. The tool converts it to UTF-8 bytes, applies RLE compression, then encodes with the 6-bit BinHex alphabet
- For decoding: paste a BinHex 4.0 block. The tool strips the header line, colon delimiters, and whitespace, then reverses the 6-bit encoding and RLE decompression
- Check the encoding steps panel to see the RLE-compressed hex bytes and the 6-bit BinHex stream
- The BinHex alphabet reference shows all 64 characters used by the encoding, so you can verify which characters are valid
- Click Swap encode/decode to reverse the operation
Real-world examples
Encoding a string with repeated bytes
Input: `AAAAAAAAB` (8 A's followed by B). RLE compression detects the run of 8 identical bytes and encodes it as `0x41 0x90 0x08` (A, marker, count=8), followed by `0x42` (B). The compressed stream is 4 bytes instead of 9. The 6-bit encoding then maps these 4 bytes to 6 BinHex characters. Without RLE, 9 bytes would produce 12 characters; with RLE, 4 bytes produce 6 characters.
Encoding a string with no repetition
Input: `Hello` (5 bytes, all unique). RLE compression finds no runs of 4 or more, so the compressed stream is identical to the input. The 6-bit encoding maps 5 bytes to 7 BinHex characters (5 * 8 = 40 bits, divided into 6-bit groups, padded). The output includes the header line, a colon delimiter, the wrapped 6-bit stream, and a closing colon.
Decoding a full BinHex block
Paste a block starting with `(This file must be converted with BinHex 4.0)` followed by a colon, the encoded stream, and a closing colon. The tool locates the first and last colon, extracts everything between them, strips whitespace, decodes the 6-bit characters back to bytes, then decompresses the RLE. If the stream contains an invalid BinHex character (one not in the 64-character alphabet), the tool reports the error with the offending character.
Handling a literal 0x90 byte
If the input contains byte 0x90 (which is the RLE marker), the compressor escapes it as `0x90 0x00`. On decompression, when the tool encounters 0x90 followed by 0x00, it outputs a literal 0x90 byte rather than interpreting it as a repeat marker. This prevents ambiguity between a real 0x90 in the data and an RLE marker. The steps panel shows this escaping in the RLE-compressed hex output.
Decoding without the header line
If you paste only the encoded stream between colons (or even without colons), the tool still decodes it. It searches for the first and last colon in the input; if none are found, it treats the entire input (minus whitespace) as the encoded body. This handles cases where the header was stripped during copy-paste.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| BinHex 4.0 | RLE + 6-bit alphabet, variable overhead | Classic Macintosh file transfer (1985-2001) |
| Base64 | 6-bit alphabet, 33% overhead | Email MIME, JWT, web data URIs |
| yEnc | Offset + escape 5 bytes, ~1-2% overhead | Usenet binary posts |
| UUencode | 6-bit alphabet, 33% overhead | Legacy Usenet, email attachments |
| AppleSingle/Double | Binary format with fork metadata | Mac file transfer (replaced BinHex) |
Limitations or considerations
BinHex 4.0 is an encoding, not encryption. It provides no confidentiality or integrity protection beyond the structural correctness of the format. There is no checksum or CRC in the basic format (though some implementations added one).
This tool processes text input, not actual Macintosh binary files with resource forks. A real BinHex encoder reads the data fork, resource fork, and Finder metadata (file type, creator code) from the Mac filesystem. This tool encodes plain text as the data fork content only, which is sufficient for understanding the encoding mechanism and decoding existing BinHex text.
The RLE compression only helps when the input has runs of 4 or more identical bytes. For typical text or random binary data, the compressed stream is the same size as the input, and the overall overhead matches base64 at approximately 33%.
The 6-bit alphabet is missing several characters that appear in standard base64. If you need standard base64, use the Base64 Encode/Decode tool. For Usenet-style encoding with lower overhead, see the yEnc Encoder. For legacy email encoding, compare with UUencode.
Frequently asked questions
What is 'BinHex 4.0'?
BinHex 4.0 is a binary-to-text encoding format developed by Yves Lempereur in 1985 for the Apple Macintosh. It encodes Mac files (including both data and resource forks) into a 7-bit-safe ASCII stream using RLE compression and a 64-character 6-bit alphabet. It is documented in RFC 1741 and was the standard way to transfer Mac files over email until MIME base64 replaced it.
How does the BinHex alphabet differ from base64?
The BinHex alphabet is `!"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[\`abcdefhijklmpqr`. It uses 64 characters but omits several that appear in standard base64 (like digits 7, lowercase g, n, o, s, t, u, v, w, x, y, z). These omissions avoided characters that caused problems on certain early mail gateways and EBCDIC-based systems.
What does the RLE marker 0x90 do?
In BinHex RLE compression, 0x90 is the repeat marker. When the compressor finds 4 or more identical bytes in a row, it outputs the byte, then 0x90, then the count. On decompression, 0x90 means 'repeat the previous byte (count - 1) more times.' A literal 0x90 in the input is escaped as 0x90 0x00 to avoid ambiguity.
Why does BinHex include the header line?
The header `(This file must be converted with BinHex 4.0)` tells mail clients and users that the following text is a BinHex-encoded file that needs to be decoded. It was a human-readable marker in an era before MIME content-type headers existed. The colon delimiters mark the start and end of the actual encoded data.
Is BinHex 4.0 still used?
BinHex 4.0 is obsolete for new use. It was replaced by MIME multipart messages with base64 encoding once Mac OS X arrived and the resource fork became less common. The `.hqx` extension identified BinHex files. The format is now found mainly in archived Mac software from the 1990s and in CTF challenges involving retro encodings.
Conclusion
BinHex 4.0 was the Macintosh world's answer to a problem that base64 later solved for everyone: how to send binary data through a 7-bit ASCII channel. The RLE compression and custom 6-bit alphabet reflect the constraints of 1980s email systems. This tool makes both stages visible so you can see how compression and encoding interact. For modern binary-to-text encoding, use Base64 Encode/Decode. For lower-overhead Usenet encoding, see the yEnc Encoder. For legacy email encoding, compare with UUencode.