Drop in a GZIP, TAR, 7-Zip, RAR, XZ, or BZIP2 archive that won't open. Browsers can natively decompress GZIP, so that gets a real per-byte CRC-32 and size check against the actual decompressed content — TAR needs no decompression at all, so its per-entry header checksum is verified directly. 7-Zip, RAR, XZ, and BZIP2 use compression this tool can't decode, so those get real structural and header-CRC checks instead: enough to tell you if the container itself is intact or truncated, without claiming to verify content it can't actually decompress.
If you're here because something threw one of these, this tool shows you exactly what's wrong and how much is recoverable:
GZIP and TAR get real content/checksum verification because a browser can natively decompress DEFLATE and TAR needs no decompression at all. 7-Zip, RAR, XZ, and BZIP2 use LZMA/LZMA2, RAR's own compression, or bzip2's block-sorting compression — none of which browsers expose a native decoder for — so for those formats this only verifies container structure and header CRCs, never the compressed content itself. A 7-Zip archive's file list is only readable when its metadata block is stored uncompressed (many real-world .7z files compress even the metadata, in which case only the signature header is checked). RAR file names and sizes are read for RAR4; RAR5 gets block-level structural and CRC checks only, not a file listing. Multi-member (concatenated) GZIP streams are decompressed correctly, but the trailer check compares against the full concatenated output, not each member individually. For true ZIP archives (including DOCX/XLSX/PPTX/JAR/APK), use ZIP Inspector instead, which does real per-entry CRC verification.