RAR vs 7z when the archive is damaged

RAR's built-in safety net: the recovery record

The one real difference between RAR and 7z when things go wrong is that RAR can carry its own repair kit. When an archive is created, WinRAR can add a recovery record: extra redundant data whose only job is to reconstruct damaged parts of the archive later. In the modern RAR5 format that redundancy uses Reed-Solomon error correction, the same family of math that protects CDs and QR codes.

The rule of thumb is simple: a recovery record repairs in-place damage up to roughly its own size. Add a 3% recovery record and you can heal about 3% of the archive's worth of damaged bytes. That's ideal for the common failure where storage flips or overwrites a band of bytes without changing the file's length: the corrupted bytes stay where they are, the record supplies the correct values, and WinRAR rebuilds the archive in place.

A RAR recovery record heals in-place damage up to about its own size — corruption that flips or overwrites bytes without changing the file's length.

The catch is what it can't do. A recovery record corrects damage that stays in position. It's useless against insertions and deletions: if bytes are added or removed, every byte after that point shifts, the record's alignment breaks, and the correction fails. It also can't help if the damage exceeds the record's capacity, or if the archive was created without a recovery record at all, which is the default. Plenty of RAR files in the wild have no record to fall back on.

7z has no safety net, and its layout makes it worse

7z compresses well, often better than RAR, but it carries zero recovery record. There is no built-in redundancy option, so any damaged byte is a byte with no backup. That alone would make 7z more fragile; its file layout compounds the problem.

A 7z archive writes its directory, the header listing every file, its size, and where its data lives, at the end of the file. That's efficient to write, but it means the map you need to make sense of the archive is the last thing on disk. The most common real-world corruption, an interrupted or truncated download, takes the tail first. Lose the end of a 7z and you often lose the directory, and without the directory the archive can be hard to interpret at all, even though most of the compressed data sits there intact.

7z keeps its directory at the end, so a truncated download tends to remove exactly the map needed to read the entries that survived.

This is the mirror image of RAR's recovery record: not just no redundancy, but a structure where the single most common corruption hits the most important part. It doesn't make 7z a bad format, its compression is a real advantage, but it does mean a damaged 7z has fewer built-in options than a damaged RAR.

Salvage extraction works on either format

When repair isn't on the table, no recovery record on the RAR, no directory on the 7z, there's still salvage. Both formats store each file's compressed data as an identifiable unit, so a tool can scan the archive, find the entries whose data is intact, and decompress those individually, even when the archive as a whole won't open.

In practice that means partial recovery: "38 of 44 files extracted" rather than all-or-nothing. An archive with a damaged region gives up the files stored before it and, often, the files after it whose data starts cleanly past the damage. It's the same principle that makes damaged ZIPs partly recoverable, and it's usually the realistic outcome for a 7z that lost its directory: the entries are still there to be carved out one by one. For the ZIP side of this, see repairing a corrupted ZIP and the Windows-specific "compressed folder is invalid" error.

Where salvage runs out: solid and encrypted archives

Salvage has hard limits, and two of them decide most outcomes.

Solid archives lose everything after the damage

Both RAR and 7z can be solid: files compressed as one continuous stream so later files reuse earlier data, which improves the ratio. The price is that decompression is strictly sequential, to reach a file you decode everything before it. When corruption interrupts the stream, the decoder can't continue past the bad point, so every file after the damage becomes unreachable even though its bytes are physically on disk. Files before the damage still come out; everything downstream is stranded. A non-solid archive avoids this because each file stands alone.

Encrypted archives need the password first

If the archive is encrypted, none of this happens without the password. Salvage and recovery-record repair both operate on data they can read, and encrypted entries are unreadable until decrypted. A recovery record can still repair the encrypted bytes in place, and salvage can still identify entries, but turning any of it back into your files requires the password. No repair tool works around encryption; that's the point of encryption.

Why browser tools do salvage, not recovery-record repair

Here's the honest line that most "RAR repair online" pages blur. Actually applying a Reed-Solomon recovery record, the operation that heals a damaged RAR in place, is a feature of paid WinRAR. No open-source library reproduces it. So when a browser tool or a free utility says it "repairs" a RAR, what it's really doing, in almost every case, is salvage: reading the archive and extracting the entries whose data survives.

That distinction matters for setting expectations. If your RAR has a recovery record and in-place damage within its capacity, WinRAR's own "Repair archive" is the tool that can genuinely reconstruct it, and it's worth trying first. If there's no recovery record, or the damage is truncation, insertion, or deletion, then repair isn't available from anyone and salvage is the realistic path, which is exactly what a browser-based tool can do, without the archive leaving your machine.

So the practical order is: if it's a RAR with a recovery record, let WinRAR try its repair. Otherwise, whether it's RAR or 7z, reach for salvage extraction and recover the intact entries. Neither approach invents data that isn't in the file; both just get the most out of what is.