Solid Compression Explained: Why One Bad Byte Ruins Later Files
Two archives can hold the same files and behave nothing alike when something goes wrong. A normal ZIP compresses each file on its own. A solid RAR or a default 7z archive compresses them as one long stream. That single choice changes how fast a one-file extract feels, and whether a few damaged bytes take out one document or half the archive.
Updated 2026-10-22 · Written and tested by the UnpackNest editorial team (TECCONET)
What "solid" means
Compression likes repetition. If you compress 200 similar PDFs separately, each PDF carries its own dictionary and you pay that overhead 200 times. If you concatenate the PDFs and compress the stream once, later files reuse patterns from earlier ones and the archive shrinks. That concatenated mode is solid compression.
ZIP, in the form people actually send, is not solid. Each entry has its own Deflate stream. RAR can be solid or not; the sender chooses, and many RAR presets turn solid on for "best" size. 7z is solid unless the sender turned it off. You cannot see the choice from the extension. You see it in the tool's method line, or you infer it when a tiny file near the end of the archive takes a long time to extract.
What you feel when you extract
Open a solid 7z in the 7z tool and extract the last file in the list. The engine may read and decode a large stretch of earlier data before your file falls out. The progress feels like "this tiny PDF is slow", but the work is the shared block. A non-solid ZIP in the ZIP tool extracts that same PDF by jumping to one entry and inflating only that entry. The central directory makes the jump possible. A solid stream has no independent jump for each file.
This is also why "extract one file" advice has a footnote for 7z and for solid RAR. You still click one row, and you still save one download. You do not, however, skip the CPU cost of the preceding solid block. On a phone that cost can get the tab killed. On a laptop it is usually just a wait. The one-file guide describes the click-path; this page describes why the wait differs.
The RAR tool will list a solid archive and extract non-encrypted entries it supports. It does not offer a switch to "make it non-solid". Solidity was fixed when the sender created the file. Only a new archive, built by them, changes it.
What you feel when something is damaged
Damage in a non-solid ZIP is local. A CRC failure on photos/img-14.jpg leaves img-15.jpg alone, because its stream never depended on img-14. The repair guide treats that as "save the good files, replace the bad one".
Damage in a solid block is a tear in a single stream. Bytes after the tear no longer decode, even when those bytes travelled intact. You can lose every file that sits after the damage inside that block, and the error may be reported only on the first file that fails. Later files then look corrupt too. Re-downloading the whole archive is the realistic fix. Rebuilding one inner file is not, because its compressed form is mixed with its neighbours.
7-Zip can use several solid blocks instead of one, controlled by a dictionary and a solid-block size at creation time. A tear then ruins the rest of that block, not necessarily the rest of the archive. You cannot guess the block boundaries from the file names. If half the files extract and half fail, you may be seeing a block boundary, or you may be seeing a truncated download. Compare the archive's size with the size the sender published before you celebrate the files that worked.
Recovery records do not cancel solidity
RAR can store a recovery record, a slice of extra data that reconstructs damaged bits. That feature is about missing or flipped bits in the file on disk. It is not a promise that each member is independent. A solid RAR with a recovery record may survive a small scrape and still be painful to extract one file from. If the recovery record itself is in the missing tail of a truncated download, it cannot help. The repair guide covers when to try rar r style recovery and when a new download is honest.
PAR2 files beside a RAR are a similar idea applied outside the archive. They can rebuild a damaged volume of a multi-part set. They do not turn a solid archive into a ZIP.
Passwords and solid archives
Encryption is orthogonal to solidity, but they show up together because the same "maximum" preset enables both. An encrypted solid 7z needs the password before any name or any file appears, if the sender encrypted the headers. A wrong password looks like total failure. It is not evidence the solid stream is damaged. Try the password carefully, including spaces, before you ask for a rebuilt archive. The password guide lists which UnpackNest tools prompt (the 7z page) and which refuse (RAR and ZIP).
If the password is correct and CRC errors then cascade from one file onward, you are back to solid damage. The password did its job. The bytes did not.
Advice if you are the person creating the archive
Turn solid off when the recipient will extract one or two files, or when the files must survive a flaky download. In 7-Zip's add dialog, solid block size can be set to non-solid. The archive grows. Extraction of one file becomes a small, independent job, and a CRC error stays on one file. Use solid when you are publishing one big source tree that everyone will unpack completely, over a channel that checksums the whole file.
For RAR, the equivalent is the solid checkbox in the compression settings. Leaving it on and also splitting into mail-sized volumes is the combination that produces the longest support threads: a missing volume plus a solid stream. Prefer a single ZIP for mail, as the comparison guide argues, unless you truly need RAR features.
Name the archive in a way that does not hide the choice. You cannot put "solid" in the extension, but you can say it in the message: "7z, solid, one volume, 180 MB". The recipient can then decide to use a computer rather than a phone.
How to tell before you wait
- The archive is 7z and the sender did not mention a special setting: assume solid.
- The archive is ZIP using Deflate or Store: assume not solid. Exotic ZIP methods are a different problem (unsupported method), not solidity.
- The archive is RAR and one small file in the middle takes as long as extracting everything before it: it is solid, or the phone is thermal-throttling. Try the same file on a computer. If it is still slow, it is solid.
- Many files fail CRC after one specific file, and the archive size matches the original: solid-block damage. Replace the archive.
- Many files fail and the archive is shorter than promised: truncation. Solidity does not matter until the download is complete.
Frequently asked questions
Will UnpackNest convert a solid archive into separate files online?
It will extract supported entries locally. It will not rewrite the archive as a non-solid ZIP on the server. If you need a non-solid copy, extract the files you are allowed to have and, if you must send them on, create a new ZIP yourself.
The 7z tool sits on "extracting" for a 20 KB file
Wait, if the tab is still responsive. A 20 KB member at the end of a solid block is gated by everything before it. If the tab is reloaded by the browser, the archive is too heavy for that device. Use a computer.
Can I see block boundaries in the file list?
Not as a column you can trust in every tool. Some desktop programs show the method as LZMA:24 or similar, which hints at a dictionary, not at which files share a block. Plan for the worst case: one file's failure can affect the files after it.
Does gzip of a TAR count as solid?
A .tar.gz is one gzip stream around one TAR. Damage in the gzip stream stops decoding after that point, so the practical effect resembles a solid archive even though TAR itself is just concatenation. The fix is the same: get an intact download. The TAR tool will list entries only as far as the stream decodes.
Tools for this task
- Open 7z files and split .7z.001 archives onlineLZMA/LZMA2, AES-256, multi-volume.
- Open and extract RAR files in your browserRAR4 and RAR5, read on your device.