Convert RPM to TAR.GZ Online (The Same Path RPM's Own Tools Use)

What an RPM-to-TAR.GZ Conversion Actually Produces

An RPM package, the format built in 1997 at Red Hat by Erik Troan and Marc Ewing, stores its actual files inside a Payload section that is a compressed cpio archive, separate from the Lead, Signature, and Header sections that carry identification data, GPG signatures, and package metadata. Converting RPM to TAR.GZ means decompressing that payload, reading each file entry out of the cpio structure, and rebuilding the same files inside a TAR container that then gets compressed with gzip — the DEFLATE-based algorithm behind the .gz extension.

This particular pairing has an unusually direct path compared with other archive targets, because gzip was RPM's own original default payload compressor for most of the format's history, before some distributions moved to bzip2, then XZ, and eventually zstd (Fedora's default since Fedora 31 in 2019, chosen for decompressing about three times faster than XZ). A TAR.GZ built from an RPM whose payload already used gzip involves less algorithmic change than converting the same package to a format using an entirely different compressor.

RPM's Internal Gzip History and Why TAR.GZ Feels Like a Natural Target

The official rpm2archive tool, distributed with rpm's own utilities on Fedora, RHEL, and openSUSE, writes its output as a .tar.gz by default rather than any other compressed format — a direct acknowledgment from the RPM project itself that gzip is the most broadly compatible choice for handing package contents to systems and tools that don't understand RPM or cpio at all. That tool decompresses the payload (whatever it was originally compressed with), re-encodes each entry using TAR's header format instead of cpio's, and recompresses the result with gzip in one pass.

Because gzip uses a comparatively small 32 KB sliding window, a TAR.GZ built this way won't match the compression ratio of a payload that was originally compressed with XZ or zstd at higher settings — those algorithms can reference matches across a much larger span of data. The tradeoff RPM's own tooling accepts is broader compatibility (gzip decoders exist virtually everywhere) in exchange for giving up some of the tighter compression newer payload formats can achieve.

This is also why rpm2archive's choice of gzip, rather than matching whatever the source RPM originally used, is deliberate rather than an oversight: the tool exists specifically to hand package contents to systems that may have no XZ or zstd library available at all, and gzip has been part of essentially every Unix-like system's base toolset since the early 1990s, decades longer than either of the newer alternatives. Picking the most universally supported compressor over the tightest possible ratio reflects what the tool is actually for — getting files out to unfamiliar systems, not producing the smallest possible archive.

What Changes When RPM Metadata Becomes a Plain TAR.GZ

• Keep — file data and Unix permissions: TAR's header preserves mode bits the same way cpio's did, so ordinary permissions on individual files survive the conversion intact.
• Keep — directory structure: relative file paths inside the payload carry over into the TAR entries without modification.
• Lose — install scriptlets: %pre, %post, %preun, and %postun scripts exist only in the RPM Header, a section rpm2archive and rpm2cpio don't touch when reading the Payload.
• Lose — the dependency list: what the package requires or provides is Header-only metadata with no equivalent field in a TAR.GZ.
• Lose — the GPG signature and digest values: RPM's Signature section, used to verify a package's authenticity before installation, has nothing corresponding to it in a plain tarball.
• Gain or lose size, depending on the original payload compressor: a gzip-based RPM payload converts to TAR.GZ with little ratio change, while an XZ- or zstd-based payload can end up noticeably larger once recompressed with gzip's smaller window.
• Gain — near-universal readability: gzip decompression support is built into far more operating systems, archive managers, and programming language standard libraries by default than either XZ or zstd decoding, so a TAR.GZ opens in more places without installing anything extra.

Tools That Turn RPM Packages Into TAR.GZ Archives Today

rpm2archive package.rpm is the most direct route on any Linux system with rpm's tools installed, producing a package.rpm.tar.gz file in a single command with no separate cpio-handling step required. The older manual approach — rpm2cpio package.rpm | cpio -idmv followed by tar -czf package.tar.gz ./extracted-folder — still works and is documented across most Linux distribution wikis, useful specifically on older systems that predate rpm2archive's inclusion.

On Windows, 7-Zip opens .rpm files directly and can browse straight into the embedded cpio payload without installing any RPM-specific software, after which the extracted files can be rearchived as a .tar.gz using 7-Zip's own archive creation dialog. PeaZip offers the same RPM-browsing and TAR.GZ-writing combination on both Windows and Linux for anyone who prefers a single graphical tool over chaining command-line utilities.

Real-World Problems Reported With RPM-to-TAR.GZ Conversions

A well-documented issue involves older rpm2cpio and cpio builds failing on modern RPM packages that contain files larger than 4 GB — RPM 4.12 and later use a stripped-down cpio format (identified by 07070X magic bytes) for those specific packages, storing only a file index rather than full metadata in the cpio header itself, and older tools that don't recognize this variant simply error out. Updating the rpm-tools package resolves it; the source RPM itself isn't damaged.

A second recurring complaint is confusion over why a converted TAR.GZ can't be used to reinstall the software — every piece of information a package manager depends on (dependencies, version, scriptlets) lives in the RPM Header, which neither rpm2archive nor rpm2cpio ever reads into the output; querying that metadata directly from the original RPM with rpm -qpi is the only way to retrieve it before or instead of converting.

A third issue that shows up specifically with packages built using zstd payload compression (the Fedora 31+ default) is that a straightforward gzip-based TAR.GZ conversion produces a noticeably larger file than the source RPM, simply because gzip's 32 KB window and older DEFLATE algorithm don't compress as tightly as zstd at level 19 — an expected result of the format swap rather than a conversion error.

A fourth issue reported around large, multi-gigabyte RPM packages (common with driver bundles or language runtimes) is that the two-step manual conversion — extracting with cpio, then compressing the result with gzip — takes noticeably longer than expected on spinning disks or constrained systems, since the extracted files temporarily need as much free disk space as their uncompressed size before the tar and gzip steps even begin; rpm2archive avoids some of this by streaming the payload through in one pass rather than writing a fully extracted copy to disk first.

RPM Package Contents Versus a Plain TAR.GZ Tarball

Frequently Asked Questions About RPM to TAR.GZ

Is there an official tool that converts RPM straight to TAR.GZ?
Yes. rpm2archive is distributed with rpm's own utilities on Fedora, RHEL, and openSUSE and writes a .tar.gz directly from a package's payload in a single command.

Why is the TAR.GZ bigger than the original RPM?
If the RPM used XZ or zstd payload compression, both generally compress tighter than gzip's smaller window and older DEFLATE algorithm — recompressing the same files with gzip can produce a larger result even though nothing was added.

Does the TAR.GZ include the package's dependency information?
No. Dependencies, version numbers, and scriptlets are stored only in the RPM's Header section, which conversion tools reading the Payload never touch.

Why did my older rpm2cpio command fail on a newer RPM?
RPM 4.12 and later use a different cpio variant for packages with files over 4 GB, and older rpm2cpio or cpio builds don't recognize its magic bytes — updating those tools fixes the failure.

Can I open the resulting TAR.GZ on a system with no RPM tools at all?
Yes — that's exactly the scenario rpm2archive was built for. Gzip decompression is supported essentially everywhere, including Windows tools like 7-Zip and PeaZip, unlike RPM or cpio support.

Does converting to TAR.GZ preserve the original file ownership shown by the RPM?
It preserves whatever numeric UID and GID values were stored in the payload, but those numbers came from the original build system and may not correspond to real user accounts on the machine doing the conversion, so ownership can look unfamiliar until it's reset manually.