Convert ISO to TAR Online (Disc Filesystem to Unix Tape Archive)

Two Formats Built for Very Different Kinds of Storage Media

An ISO file is a complete ISO 9660 or UDF filesystem image, standardized by the International Organization for Standardization in 1988 to represent exactly what sits on an optical disc — volume descriptors, a path table, directory records, and, on bootable discs, a boot catalog, all built around fixed 2048-byte sectors. TAR (Tape ARchive) comes from an entirely different lineage: it's a Unix format from the 1970s, originally designed to stream files sequentially onto magnetic tape drives, and it stores each file as a simple header block (with the file's name, size, permissions, and ownership) immediately followed by that file's raw data, one after another, with no central directory or index anywhere in the file.

Converting ISO to TAR means walking the disc image's filesystem tree the same way any extraction does, then writing each file out as a TAR header-plus-data block in sequence. TAR itself applies no compression by default — a plain .tar file is exactly as large as the sum of its contents plus header overhead, which is part of why TAR is so often paired with a separate compressor like gzip or bzip2 to produce the .tar.gz or .tar.bz2 formats also used for archiving disc contents.

TAR's Unix Heritage Actually Matches Rock Ridge's Metadata

This is the one pairing among the six archive targets where something unusual happens: TAR's header format was built from the start to carry Unix filesystem metadata — file owner and group IDs, POSIX permission bits, and symbolic links — as core, mandatory fields, not optional extras. Rock Ridge, the Unix/Linux extension to ISO 9660, was specifically designed to carry that same category of metadata (ownership, permissions, symlinks, and filenames up to 255 bytes) on a disc that would otherwise only support 8.3 filenames with no ownership concept at all. Because both formats were built around the same Unix filesystem model, a Rock Ridge–enabled ISO converts to TAR with its permission bits and symbolic links intact in a way that converting the same disc to ZIP typically does not, since ZIP's central directory has no standard, universally supported field for POSIX ownership.

This only applies when Rock Ridge extensions are actually present on the source disc, though. A disc authored with only plain ISO 9660 (Level 1 or 2) or only the Windows-oriented Joliet extension carries no POSIX permission or ownership data at all, so there is nothing for TAR to preserve beyond the file names and content in that case — TAR's Unix-heritage advantage is specifically a Rock Ridge advantage, not a universal property of every ISO.

What Survives the Move From Disc Image to Tape Archive

• Gain, if Rock Ridge is present — POSIX permissions and symlinks: TAR's header format natively carries ownership, permission bits, and symbolic link targets, matching what Rock Ridge encodes on the disc.
• Lose — the El Torito boot record and boot catalog: plain TAR has no concept of a boot sector or bootable media, so a bootable installer ISO becomes a non-bootable file archive.
• Lose — any compression, unless paired with gzip or bzip2: a plain .tar file is uncompressed, meaning a TAR built straight from an ISO's files can end up roughly the same size as the disc image, not smaller.
• Lose — virtual-drive mounting: TAR archives are opened by an archive tool; they aren't mountable as a virtual optical drive the way an ISO is on Windows 8+ or macOS.
• Lose — Joliet's long-filename tree, if Rock Ridge isn't also present: without Rock Ridge, TAR still gets whichever single resolved filename tree the extracting tool chooses, not the disc's alternate 8.3 fallback names.
• Gain — a format readable by essentially every Unix and Linux system without extra software: tar is a standard command-line utility on virtually every Linux distribution and macOS, unlike RAR or 7z, which need separate installation.

Where TAR Extraction From an ISO Actually Works Cleanly

The tar command ships as a standard utility on essentially every Linux distribution and on macOS, and mounting an ISO on either platform (natively on macOS via Disk Utility, or with the mount command's loop device option on Linux) followed by a plain tar -cf command against the mounted contents is a routine way system administrators archive disc contents while keeping Unix ownership and permission data intact. On Windows, native ISO mounting has been available since Windows 8, but the tar command line utility was only added to Windows itself starting with Windows 10's 2018 update — before that, a separate tool like 7-Zip or a WSL (Windows Subsystem for Linux) environment was needed to produce a proper TAR file with Unix metadata preserved.

7-Zip on Windows can also read an ISO's contents directly and write them out as a TAR archive, but it's worth noting that 7-Zip's TAR writer does not necessarily capture POSIX ownership and permission data the way a native Unix tar command run against a Rock Ridge–mounted ISO does, since Windows itself has no concept of Unix user/group IDs to read from the source files in the first place — the Rock Ridge permission advantage described earlier is realized fully only when both the reading and writing steps happen on a Unix-aware system.

TAR has no built-in size limit that comes up in ordinary use, and its lack of any central directory means it can be built as a genuine append-only stream — new files can be added to the end of an existing TAR without touching what's already there, a property inherited directly from its original design for sequential magnetic tape drives.

Problems That Actually Come Up Converting Disc Images to TAR

A common complaint on Linux and sysadmin forums involves a TAR built from an ISO turning out to be nearly the same size as the original disc image, which surprises users expecting compression — this is expected behavior, since plain tar applies none; the fix reported repeatedly is using tar's built-in -z or -j flags (or building a .tar.gz or .tar.bz2 directly) rather than assuming plain TAR would shrink anything.

A second recurring issue involves permissions not surviving the conversion when a Windows tool was used to read the ISO and write the TAR — users expecting a Rock Ridge disc's Unix ownership data to appear in the resulting TAR are often working with a tool that never read that Rock Ridge metadata in the first place, since Windows-based extractors frequently resolve only the Joliet tree by default, silently dropping the POSIX fields Rock Ridge carries alongside it.

A third issue is the same one that comes up with every archive-format conversion from a bootable ISO: users who convert an installer disc to TAR to save space, then try to use the TAR file to reinstall an operating system, find nothing about TAR's format supports booting a computer, since the El Torito boot catalog simply isn't representable in TAR's header-and-data-block structure.

ISO and TAR Compared Directly

Questions About Archiving a Disc Image as TAR

Will converting my ISO to TAR make it smaller?
Not by itself. Plain TAR applies no compression, so the result is typically close to the size of the disc's actual files. Pairing it with gzip or bzip2, as in tar.gz or tar.bz2, is what actually shrinks it.

Does TAR preserve Unix file permissions from an ISO?
Yes, but only if the source ISO carries Rock Ridge extension data and the extraction happens on a Unix-aware tool or system; a disc with only plain ISO 9660 or Joliet has no permission data to preserve in the first place.

Can a TAR file made from an installer ISO still boot a computer?
No. TAR's format has no equivalent to the El Torito boot record and boot catalog, so bootability is lost regardless of which archive format the disc's files get converted to.

Is TAR available on Windows without installing anything?
Yes, starting with a 2018 update to Windows 10, which added the tar command line utility built in. Earlier Windows versions needed a separate tool like 7-Zip.

Why did the permissions disappear when I made a TAR from an ISO on Windows?
Windows-based extraction tools typically read the Joliet filename tree by default and don't parse Rock Ridge's Unix ownership and permission data, since Windows itself has no concept of those POSIX fields to apply.