Convert ISO to TAR.GZ Online (Disc Image to Gzip-Compressed Tarball)

One Disc Format Meets a Compressor Paired Onto a Sequential Archive

An ISO file is a complete ISO 9660 or UDF filesystem image, reproducing exactly what an optical disc carries — volume descriptors, a path table, directory records, and on bootable media, a boot catalog — all matched to fixed 2048-byte sectors, with no compression applied anywhere in the standard. A .tar.gz file is two formats working together: TAR packages files sequentially into header-plus-data blocks with no central directory, and gzip, based on the same DEFLATE algorithm used in ZIP and first released by Jean-loup Gailly and Mark Adler in 1992, compresses that entire TAR stream afterward as one continuous pass.

Converting ISO to tar.gz means reading through the disc image's filesystem the same way any extraction does — following its path table and directory records to find every actual file — packaging those files into an uncompressed TAR stream, and then running gzip's DEFLATE compressor over the result. As with every other archive target, none of the disc's own sector layout, volume descriptors, or boot structure survives; only the visible files that a filesystem browser would show inside the mounted disc make it into the tarball.

Gzip's Smaller Window Trades Compression Ratio for Speed

Gzip's DEFLATE algorithm works with a 32 KB sliding window, looking for repeated byte sequences only within that recent span of data, which is considerably smaller than bzip2's up to 900 KB block size used in the tar.bz2 alternative. That smaller window generally means gzip compresses the same disc contents to a slightly larger file than bzip2 would, but it also means gzip runs meaningfully faster in both directions — compressing and decompressing — since there's simply less analysis happening per byte of data. For a large ISO, this speed difference is the whole reason tar.gz remains the more commonly used default pairing over tar.bz2 in many Linux distributions and package systems, even when bzip2 could squeeze out a somewhat smaller file.

This is the same trade-off documented across general compression benchmarks, not something specific to disc images — gzip favors speed, bzip2 favors ratio, and choosing between tar.gz and tar.bz2 for a converted ISO comes down to whether the priority is finishing the compression quickly or ending up with the smallest possible file.

Package managers on major Linux distributions have historically leaned on gzip-based compression for exactly this reason: when a system is unpacking hundreds of small package archives during a software installation or update, the cumulative time savings from gzip's faster decompression add up in a way that matters more than shaving a few extra percent off each individual file's size, which is a large part of why tar.gz remains the more commonly encountered default even where tar.bz2 or newer alternatives could compress somewhat further.

What Survives Packaging a Disc Image Into a Gzip Tarball

• Gain — noticeably faster compression than tar.bz2: gzip's smaller sliding window and simpler algorithm process the same disc contents in less time, at the cost of a somewhat larger resulting file.
• Gain, if Rock Ridge is present on the source disc — POSIX permissions and symlinks: TAR's header format natively carries Unix ownership and permission data, matching Rock Ridge's disc-side metadata.
• Lose — the El Torito boot record and boot catalog: neither TAR nor gzip has any concept of a bootable disc structure, so a bootable installer ISO becomes non-bootable once converted.
• Lose — virtual-drive mounting: a tar.gz has to be decompressed and extracted with an archive tool, unlike an ISO, which mounts directly as a virtual optical drive.
• Gain — near-universal support on Unix systems: gzip and tar are both standard, built-in command-line tools on essentially every Linux distribution and macOS.
• Gain, since Windows 10's 2018 update — native decompression on Windows too: Windows' built-in tar command can extract a .tar.gz directly, unlike a .tar.bz2, which it cannot decompress on its own.

Where This Specific Pairing Gets Native Support and Where It Doesn't

Linux distributions and macOS both ship tar and gzip as standard command-line utilities, and the tar command's -z flag pipes its output through gzip in a single step, making tar.gz creation from a mounted ISO a routine, one-command operation on either platform without installing anything extra. Windows 10's 2018 update added a built-in tar command that can both create a plain tarball and directly decompress an existing .tar.gz file, which is a real, documented improvement over tar.bz2 support — Windows' native tar still cannot decompress bzip2-compressed archives on its own, only gzip-compressed ones.

7-Zip on Windows can also read an ISO's contents directly and write a tar.gz from them in a single workflow, which is useful for anyone on an older Windows version predating the built-in tar command. As with any Windows-based extraction of a Rock Ridge–enabled ISO, though, the resulting tar.gz will not carry Unix ownership and permission metadata unless the extracting tool specifically reads and preserves Rock Ridge's System Use fields, since Windows itself has no native concept of POSIX user or group IDs to apply to the extracted files.

Gzip has a documented practical limitation worth knowing: because it stores the uncompressed file's size in a 32-bit field within its own header, files or streams larger than 4 GB can report an incorrect size after decompression on some older gzip implementations, though this rarely affects tar.gz specifically since the size that matters is read from TAR's own header structure inside the decompressed stream, not gzip's outer header.

That header quirk becomes relevant mainly for tools that rely on gzip's own reported size to preallocate buffers or show a progress estimate before decompression starts — on a large Blu-ray ISO converted to tar.gz, well past 4 GB uncompressed, such a tool might display an incorrect or wrapped-around size figure during extraction, even though the actual file data extracts completely and correctly once TAR's internal headers take over describing each entry.

Complaints Specific to Converting Disc Images Into TAR.GZ

A common report among users comparing tar.gz against tar.bz2 for the same ISO is confusion over why the gzip version is a bit larger — this is expected and documented: gzip's DEFLATE algorithm uses a much smaller compression window than bzip2's block-sorting approach, so it reliably produces a somewhat larger file on the same source data in exchange for compressing and decompressing considerably faster.

A second recurring issue, identical to the one seen with tar.bz2, is Unix ownership and permission data going missing when the extraction step runs on Windows rather than Linux or macOS — Windows-based tools frequently read only the Joliet filename tree from a disc by default, and Rock Ridge's POSIX metadata sits in a different part of the ISO 9660 structure that not every Windows extractor parses.

A third issue is the now-familiar one for any bootable-ISO conversion: someone converts an installer disc to tar.gz for easier long-term storage, then discovers the tarball cannot be used to boot a computer, since the El Torito boot catalog that made the original ISO bootable has no representation inside either TAR's header structure or gzip's compression stream.

ISO and TAR.GZ Compared Directly

Questions About Compressing a Disc Image Into TAR.GZ

Should I pick tar.gz or tar.bz2 for a converted ISO?
Tar.gz compresses and decompresses faster; tar.bz2 usually produces a somewhat smaller file. The choice comes down to whether speed or final file size matters more for a given disc image.

Can Windows open a tar.gz file without installing anything?
Yes, as of the 2018 update to Windows 10, which added a built-in tar command that decompresses gzip-compressed tarballs automatically — this is not true for tar.bz2, which still needs a separate tool.

Does converting a bootable ISO to tar.gz keep it bootable?
No. Neither TAR's header format nor gzip's compression stream has any equivalent to the El Torito boot catalog that makes a disc image bootable, so that capability is lost regardless of the target format.

Will Unix permissions from my ISO survive in the tar.gz?
Only if the source disc carries Rock Ridge extension data and the extracting tool reads it; a disc with only plain ISO 9660 or Joliet has no POSIX permission data to preserve in the first place.

Why is my tar.gz slightly bigger than the tar.bz2 version of the same ISO?
Gzip's DEFLATE algorithm uses a much smaller compression window than bzip2's block-sorting method, so it reliably trades a somewhat larger file for considerably faster compression and decompression.