Decode a BinHex .hqx file
A .hqx file is BinHex: a complete Macintosh file — both forks, the type and creator codes, a checksum — converted into printable text so it could survive being pasted into an email or posted to Usenet. Drop one here. It is decoded in your browser and handed to an emulated Macintosh with everything still attached.
Everything happens in your browser. Your file is never uploaded anywhere.
What BinHex is
Open a .hqx in a text editor and you will see this at the top:
(This file must be converted with BinHex 4.0)
:#R0KEA"XC5j15%!!N!3!!!!!...That first line is literal, and it is the format's entire origin story. In the 1980s and early 1990s the way you sent someone a file was to put it in the body of an email or a Usenet post, and the systems it passed through were built for seven-bit text. Any byte with the high bit set could be mangled or dropped. So BinHex encodes the whole thing — data fork, resource fork, Finder metadata, and CRCs to catch damage — into a restricted alphabet of 64 safe characters, run-length compressed first to take the edge off the size penalty.
Version 4.0, by Yves Lempereur, is the one that stuck, and it is what essentially every .hqx you will encounter uses.
Why you cannot just rename it
People try. A .hqx is text, so it looks like something a text editor should be able to save out. It is not: the payload is encoded, not merely wrapped, and even after decoding you have a two-fork Macintosh file that a Windows or Linux filesystem has no way to store.
Very often the decoded contents are themselves a StuffIt archive — .sit.hqx was the canonical way to distribute Mac software by email for a decade. So the full journey is BinHex to StuffIt to application, and only the last step tells you whether the first two worked.
Decoding here happens in JavaScript in your browser, and what comes out is written into the emulated Mac's filesystem with its resource fork in the right place. If it is a StuffIt archive, Expander is on the disk waiting.
The other formats in the same family
MacBinary (.bin) solves the same problem with a binary container rather than text: a 128-byte header holding the filename, type, creator and fork lengths, then the data fork, then the resource fork, each padded to 128 bytes. It is more efficient than BinHex and was preferred wherever the transport was eight-bit clean, such as FTP in binary mode.
AppleSingle and AppleDouble do the same job again for A/UX and network filesystems; AppleDouble is why a Mac-made ZIP contains a __MACOSX folder full of files whose names start with a dot underscore. Those are the resource forks.
All of them are here for the same reason: a Macintosh file was never just a stream of bytes, and every other system in the world assumed it was.
Questions people ask
What is a .hqx file?
A Macintosh file encoded with BinHex 4.0 — both forks and the file's metadata converted into plain printable text so it could be sent through email or Usenet without corruption.
Can I open a .hqx on a modern Mac?
Not out of the box. Mac OS X dropped BinHex support along the way. The Unarchiver handles it, or you can decode it here.
Why is my .hqx bigger than the file inside it?
Because encoding eight-bit data into a six-bit safe alphabet costs about a third in size. BinHex applies run-length compression first, which claws some of it back.
What do I do with what comes out?
Very often the decoded file is a StuffIt archive. Double-click it on the emulated Mac and StuffIt Expander will expand it.
What is the difference between BinHex and MacBinary?
Same purpose, different container. BinHex is text and survives anything; MacBinary is binary, smaller, and needs a transport that will not mangle high bytes.
Is my file uploaded?
No. Decoding happens in your browser, in JavaScript.