Why Old Mac Files Won't Open, and What to Do About It
September 2026 · Andrew Nakas
You have found something from an old Macintosh. A .sit, a .hqx, a .bin, an .img, or a file with no extension at all that every program on your computer refuses. Here is why, and what actually works.
A Macintosh file was two files
Every other system in 1984 agreed that a file is a sequence of bytes. The Macintosh had two sequences per file. The data fork is the one everybody else has. The resource fork is a small structured database of typed, numbered records: icons, menus, dialogue layouts, sounds, fonts, and — for an application — the executable code itself.
This was genuinely good design on a Mac. It meant a program's translatable strings lived in an editable database rather than compiled into the binary, and it is why a tool like ResEdit could let an ordinary user change the text of a menu in a shipped application.
It was catastrophic everywhere else. Copy a Macintosh application to a DOS floppy, an FTP server, or a Unix mail spool, and the resource fork was silently discarded. You were left with a file of exactly the right name and a plausible size that did absolutely nothing, because the code had been in the fork that went missing.
And it had no file extensions
The Mac identified a file by two four-character codes stored outside the file: a type (TEXT, APPL, PICT) and a creator, naming the application that made it. That is why double-clicking a document opened the right program without anything in the filename saying so, and it is also why a Macintosh file that crossed to another system lost the knowledge of what it even was.
So a file arriving from a Mac could lose its code, its icon and its identity, all without any error being reported anywhere.
Every format you will meet exists to fix this
MacBinary (.bin) packs everything into one ordinary stream: a 128-byte header with the filename, type, creator and fork lengths, then the data fork, then the resource fork, each padded to a 128-byte boundary. Version II added a CRC of the header, which is the only reliable way to tell a MacBinary file from something that happens to start with a zero byte.
BinHex (.hqx) does the same and then encodes the result as printable text, because in 1988 the way you sent a file to someone was to paste it into an email. Open one in a text editor and the first line says "This file must be converted with BinHex 4.0" — a literal instruction to a human, which is a lovely artefact of the era. The payload is run-length compressed and then packed six bits at a time into a 64-character safe alphabet.
StuffIt (.sit) compresses and archives while preserving all of it, and it won the Macintosh completely. Raymond Lau wrote the first version in 1987 as a teenager. If you downloaded Mac software between 1988 and 2005, you downloaded a .sit.
AppleDouble splits a file into two, which is why a ZIP made on a Mac contains a __MACOSX folder full of files whose names begin with ._. Those are the resource forks, kept beside the data because ZIP has nowhere else to put them.
Disk images (.img, .dsk, DiskCopy 4.2) sidestep the whole question by copying an entire HFS filesystem, forks and all.
Why modern extractors half-work
Two failures stack. The first is format coverage: there is no official StuffIt implementation any more — Aladdin became Allume, Allume was bought, and the Expander was quietly discontinued — so what remains are reverse-engineered readers. The Unarchiver's XADMaster engine is genuinely good and handles most of it, but older StuffIt versions are patchy.
The second failure is the one that catches people who think they have succeeded. Extract a Macintosh application on Windows or Linux and the extraction reports success, because it did succeed at reading the archive. But the host filesystem has nowhere to store a resource fork, so the application comes out stripped. It exists. It is the right size. It will never run.
What actually works
Give the file back to a Macintosh. On an HFS volume the forks have somewhere to live, the type and creator codes mean something, and StuffIt Expander from 1997 reads every StuffIt version that existed before it.
That is what the loader on this site does: it identifies the file from its bytes rather than its name, decodes BinHex and MacBinary in your browser with the forks intact, strips DiskCopy headers off raw images, and hands the result to an emulated Macintosh running System 7. Nothing is uploaded — the emulator is WebAssembly in your own tab.
There are format-specific pages too, for .sit, .hqx, disk images, .toast and .dmg, each of which explains what it is looking at.
One honest caveat: if your file is a Mac OS X or macOS application, none of this helps. That is a different computer wearing the same brand, and no emulator on this site will run it.