> macintosh | classic | vintage <

BinHex 4.0 is a binary-to-text encoding format created for classic Macintosh computers to safely transfer files through text-only systems while preserving Mac-specific metadata.

BinHex was developed to allow Mac files with resource forks to be transmitted through email and bulletin board systems that only supported 7-bit ASCII text.

While modern systems rarely use BinHex, it's still relevant for vintage Mac enthusiasts, archival purposes, and when working with classic Mac software and files.

BinHex uses a different 64-character alphabet, includes CRC checksums, and can encode Mac-specific file metadata like resource forks and file types.

A BinHex 4.0 file has a distinctive multi-part structure:
1. Comment line — human-readable description, often (This file must be converted with BinHex 4.0).
2. Start marker — a single colon :.
3. Encoded stream — the Mac file broken into chunks:
  • Filename length byte + filename
  • File type (4 bytes, e.g., TEXT, APPL)
  • File creator (4 bytes, e.g., ttxt for SimpleText, MACS for Finder)
  • Finder flags (2 bytes)
  • Data fork length + Resource fork length (4 bytes each)
  • Header CRC (2 bytes)
  • Data fork bytes + CRC
  • Resource fork bytes + CRC
4. End marker — another colon :.
The whole stream is RLE-compressed (0x90 = repeat marker), then encoded with BinHex's 64-character alphabet.

BinHex 4.0 uses a specific 64-character alphabet — not the same as Base64:
!"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr
Notice the deliberate omissions: no ., no /, no O (capital O), no 7 after 6, and more. These were chosen to avoid characters that looked similar in 1980s Mac fonts and to skip problematic characters in email transports. This is why BinHex and Base64 are not interchangeable even though both are 64-character binary-to-text encodings.

A .hqx file is BinHex 4.0 output. To open one on modern systems:
macOS (classic workflow): StuffIt Expander (free) handles .hqx, .sit, and .bin files natively. Even modern macOS still supports it via the App Store version.
Linux: sudo apt install macutils → hexbin file.hqx — produces a .data (data fork) and .rsrc (resource fork) pair.
Python: import binhex; binhex.hexbin('file.hqx', 'output') (deprecated in 3.9, removed in 3.11).
Online: our tool decodes the BinHex stream to raw bytes, but won't reconstruct Mac resource forks — for that use a dedicated macOS tool.

Classic Mac OS (System 1 through Mac OS 9) stored two parallel streams for every file:
• Data fork — the actual content bytes (what you'd call a file on Linux or Windows).
• Resource fork — structured metadata: icons, dialog layouts, sound clips, menu definitions, code segments for applications.
A Mac application without its resource fork wouldn't even launch — the UI and icons lived there, not in the data fork. When you transferred a Mac file to Windows or Unix, the resource fork would be stripped unless you used MacBinary, BinHex, or AppleDouble. BinHex was the most common format for email and Usenet transfers in the classic Mac era. Mac OS X (2001) moved away from resource forks toward application bundles, but legacy .hqx files remain in archives.

All three preserve Mac file metadata across non-HFS filesystems, but differ in format:
• MacBinary — binary format, prepends a 128-byte header with all Finder metadata, then the data and resource forks. Extension: .bin. Not 7-bit safe.
• BinHex 4.0 — text format (7-bit ASCII), encodes MacBinary-like metadata plus compression. Extension: .hqx. Email-safe.
• AppleSingle / AppleDouble — Apple's own format. AppleSingle stores everything in one file; AppleDouble splits data fork into the main file and metadata into a ._filename sidecar (which is why Mac-created USB drives show ._ files everywhere on Linux/Windows).
BinHex's advantage was email compatibility; the others favored speed at the cost of 8-bit cleanliness.