"Cannot open file '<name>.7z' as archive"

A .7z is built in an unusual order, and that order is the whole reason for this error. The file opens with a 32-byte signature header: the six magic bytes 37 7A BC AF 27 1C, two version bytes, a 4-byte CRC, and then a 20-byte Start Header. That Start Header does not contain your files — it contains three numbers: NextHeaderOffset, NextHeaderSize, and NextHeaderCRC. In other words, the very front of the archive is just a pointer to a second header stored at the tail of the file, after all the compressed data. That trailing structure — 7-Zip's End Header, or header database — is what actually describes every file: its name, size, CRC-32, and which compressed stream it lives in.

So when you open a .7z, 7-Zip reads the 20-byte Start Header, jumps to NextHeaderOffset (measured from the end of the signature header), and reads NextHeaderSize bytes to learn the contents. If it cannot do that, it has no list to show and raises "Cannot open file as archive". Three things break that jump. Most common by far is a truncated download: the transfer stopped before the tail arrived, so NextHeaderOffset now points past the last byte on disk and the End Header simply is not there. Second is a stray prefix — extra bytes wedged in front of the 37 7A BC AF signature, from a mangled email/MIME decode, an HTML "can't scan this file" page saved under a .7z name, two files concatenated by accident, or a self-extracting .exe stub that no longer runs. Every offset in the file is now shifted, so the pointer lands in the wrong place. Third is a flipped or zeroed byte inside the Start Header or the End Header itself; because 7-Zip verifies both with a CRC, a single bad byte makes it reject the header rather than trust a corrupt index.

One extra twist makes 7z fail harder than a ZIP here: 7-Zip usually stores its End Header compressed (an "encoded header"). The program has to decode that little block before it knows anything at all about your files — so if the encoded header is truncated or has one wrong byte, there is no partial reading of the index. It is all or nothing, and "nothing" is this exact message.

7-Zip is unusually precise about where it gave up, and the exact wording tells you which problem you have — worth reading before you try anything, because they are not the same failure.

• "Cannot open file as archive" — an open-time failure. 7-Zip could not read the End Header, so it never produced a file list. This is the header/pointer problem above: a missing tail, a stray prefix, or a bad header CRC. You are on the right page.
• "Unexpected end of data" / "Unexpected end of archive" — an extract-time failure. Here the header was readable, 7-Zip showed you the file list, and then a packed stream ran out mid-file while extracting. That is truncation of the data rather than the index — see "Unexpected end of archive" for that family across 7-Zip, WinRAR and tar.
• "Data error" / "CRC failed" — also extract-time, but a byte in the middle is wrong, not missing. The archive is full length, 7-Zip opened it fine, and one entry's decompressed bytes do not match the CRC-32 stored in the header. That is bit-rot in a single member, not a broken index.
• "is not archive" — 7-Zip could not find the 37 7A BC AF 27 1C signature anywhere it looked, so the file may not be a 7z at all (or the prefix in front of it is very large).

If your message is specifically "Cannot open file as archive", the diagnosis is the header, not the payload — which is good news, because the payload is the part that is usually still intact.

The compressed data in a .7z sits before the End Header, so a broken or missing tail does not touch the bytes that arrived first. IntactFile works with the structure directly instead of trusting the pointer 7-Zip could not follow. The cleanest case is the stray prefix: the tool scans for the 37 7A BC AF 27 1C signature, strips whatever junk sits in front of it, and re-anchors the file to the true start. If the archive behind that prefix is otherwise whole, the End Header is now reachable again and the archive opens completely — every file, exactly as authored. This is the same idea our video engine uses when it strips stray bytes before an ftyp box: the container was fine, it was just misaligned.

When the tail is genuinely missing — the truncated-download case — there is no End Header to re-anchor to, so the tool rebuilds what it can: it re-reads the signature and Start Header, re-scans the packed streams that survived, and reconstructs enough of the directory to decode the coder streams that completed before the cut. Every member whose compressed block finished arriving is salvaged and written out; the ones that did not finish, or that lived entirely in the missing tail, cannot be conjured. All of this runs as plain TypeScript inside your browser tab — no 7-Zip install, no command line, and you can watch the Network tab confirm that zero bytes of a private archive ever leave your machine.

Be clear-eyed about this one: a headerless .7z is the hardest common archive to salvage, and it is worth knowing why. In a ZIP, every file is preceded by its own self-describing local header (PK\x03\x04) with the name and compression method, so a forward scan can rebuild a lost index from the entries themselves. A .7z has no per-file headers in the data area — the packed streams are just concatenated compressed bytes, and all the metadata (names, sizes, CRCs, coder settings, stream boundaries) lives only in that one End Header at the tail. Lose it entirely and there are no signposts left in the payload; recovery depends on reconstructing structure the format never duplicated.

7z's default of solid compression tightens the ceiling further. Solid mode chains many files into a single LZMA/LZMA2 stream (a 7z "folder") to compress better, so the decoder is stateful: once the stream is cut, everything after the last complete block is unrecoverable, even files whose bytes technically arrived, because they cannot be decoded without the state that preceded them. And nothing anywhere can return bytes that never reached your disk — if the download stopped at 70%, the final 30% does not exist locally, and the real fix for that is to download the archive again, ideally with a client that supports HTTP range requests so it can resume instead of restarting. A password-protected .7z (7z uses AES-256, and can encrypt the header itself) cannot be opened or scanned without the password, because both the index and the data are ciphertext with no structure to follow. What repair reliably prevents is a partly-arrived or misaligned archive becoming a total loss — and it does it without ever copying your files to someone else's server.