Convert RPM to ZIP Online (Handing Package Contents to Non-Linux Systems)
An RPM's file data sits inside a cpio archive, not a ZIP-compatible structure — converting means extracting that payload first, since nothing in the RPM format maps directly onto ZIP's own container.
- Add a file Choose or drop it here
- Pick the format Change it whenever needed
- Download the result After conversion completes
What an RPM Package Looks Like Once It Becomes a ZIP
RPM, the package format built at Red Hat in 1997 by Erik Troan and Marc Ewing, is structured as four sections in sequence: a 96-byte Lead used for file identification, a Signature section holding GPG signatures and digest values, a Header carrying every piece of package metadata (name, version, dependencies, file list, install scriptlets), and a Payload that's actually a compressed cpio archive of the real files. Converting RPM to ZIP means reaching past the first three sections entirely, decompressing the Payload, and rebuilding each file entry inside a ZIP container, which uses PKWARE's own local-header-plus-central-directory structure rather than cpio's sequential entry format.
This particular conversion has practical value specifically because ZIP, unlike cpio or tar, opens natively in Windows File Explorer and macOS Finder without any extra software — turning an RPM into a ZIP is often the difference between a package's files being reachable on a non-Linux machine at all versus not.
This kind of conversion tends to come up in a specific, recognizable situation: someone downloads a Linux software package to inspect a configuration file, a document, an icon set, or some other piece of content bundled inside it, but is working from a Windows or macOS machine that has no RPM package manager installed and no plan to install one just to look at a handful of files. Rather than setting up a Linux virtual machine solely to run rpm -qlp or extract the package properly, converting straight to ZIP gets the same file contents into a format the operating system already understands.
Cpio, Not ZIP's Own Format, Is What's Really Inside an RPM Payload
The cpio format inside an RPM's Payload is historically the SVR4 variant with a CRC checksum, and since RPM version 4.12 a stripped-down cpio variant (identified by 07070X magic bytes) is used specifically for packages containing files over 4 GB — in that variant, the cpio header stores only a numeric index pointing back to the RPM's own Header for the actual filename and metadata, rather than storing it directly in the cpio entry itself. Neither of these is anything ZIP tools understand natively, so getting from RPM to ZIP always passes through an intermediate decompression-and-reread step, typically rpm2cpio piped into cpio -idmv to lay the files out on disk, followed by a normal ZIP-creation pass over that extracted folder.
7-Zip takes a shortcut around the manual two-tool pipeline by opening .rpm files directly in its own file browser, drilling straight into the embedded cpio structure without the user running rpm2cpio at all, after which the same tool can write the extracted contents out as a ZIP using its built-in archive-creation dialog — useful specifically on Windows, where rpm2cpio isn't a standard system tool the way it is on RPM-based Linux distributions.
What's Preserved and What's Lost Turning RPM Into ZIP
- Keep — the actual file contents: the bytes of every file in the payload carry over unchanged; only the surrounding container and compression differ.
- Keep, partially — Unix permission bits: ZIP has an extended attribute field that can store Unix mode bits, but not every ZIP tool writes or reads it consistently, so permission preservation depends on which specific tool performs the conversion.
- Lose — install scriptlets: %pre, %post, %preun, and %postun scripts are stored in the RPM Header, a section that cpio-reading conversion tools never touch, so there was nothing to carry into the ZIP.
- Lose — the dependency graph: which packages this one needs or provides exists only as Header metadata, with no equivalent field anywhere in the ZIP specification.
- Lose — the GPG signature and digests: RPM's Signature section, used to verify a package hasn't been altered, has no counterpart in a plain ZIP archive.
- Gain — direct openability on Windows and macOS: ZIP support is built into both operating systems' file managers, unlike RPM or cpio, which need dedicated tools even just to browse.
Where RPM-to-ZIP Conversion Is Actually Documented and Supported
On Linux, the standard documented route is rpm2cpio package.rpm | cpio -idmv to extract the files, followed by the zip -r package.zip ./extracted-folder command from the Info-ZIP tools to bundle them; this two-step sequence appears across most major Linux distribution wikis and support pages as the standard way to hand RPM contents to a non-RPM system. rpm2archive, the officially distributed rpm utility, writes only to .tar.gz by default and has no ZIP output option, so it doesn't cover this specific conversion path on its own.
7-Zip and PeaZip both handle the entire process graphically on Windows: opening the .rpm directly, browsing into the cpio payload, and writing a fresh ZIP from the extracted files, all inside one application. The older Altap Salamander file manager's dedicated RPM plugin covers the browsing and extraction half of this on Windows as well, though producing the final ZIP with that specific tool still requires a separate archiving step afterward.
Real Complaints From People Extracting RPM Contents Into ZIP
A recurring, documented problem is rpm2cpio failing against newer RPM packages built with files over 4 GB, since RPM 4.12 and later use the stripped-down 07070X cpio variant that some older cpio and rpm2cpio builds don't recognize — the practical fix is updating the rpm-tools package rather than assuming the RPM itself is corrupted.
A second common source of confusion is expecting the resulting ZIP to preserve Unix ownership and executable permission bits reliably — ZIP's extended attribute fields can technically hold this data, but support is inconsistent across tools, and a ZIP opened later on Windows, where Unix permission concepts don't apply the same way, often shows every file as simply readable and writable rather than reflecting the original mode bits at all.
A third issue involves numeric file ownership inside the original cpio payload: RPM packages commonly record UID and GID values tied to whatever build system created them, and those numeric IDs rarely match any real account on the machine performing the conversion, which can leave the extracted files owned by unfamiliar or nonexistent users before they're even bundled into the ZIP.
A fourth complaint, specific to symbolic links inside certain RPM packages, involves the link sometimes being converted into a plain regular file containing the link's target path as text, rather than a working symlink, once it passes through a ZIP archiver that doesn't specifically implement Unix symlink support — the ZIP specification does have a way to record symlinks using the same Unix extended attribute mechanism as permission bits, but, just like permissions, not every ZIP-writing tool implements it, so results vary depending on which archiver performs the final step.
RPM and ZIP Compared on the Details That Matter
| Aspect | Original RPM | Converted ZIP |
|---|---|---|
| Container for file entries | Cpio | ZIP (local headers + central directory) |
| Native support on Windows/macOS | No — needs a dedicated tool | Yes — built into both file managers |
| Unix permission bits | Reliably stored in cpio header | Stored inconsistently, tool-dependent |
| Dependency metadata | In Header section | Not present |
| Install scriptlets | In Header section | Not present |
| GPG signature | In Signature section | Not present |
| Official one-step conversion tool | N/A | None — requires rpm2cpio plus zip |
Common Questions About Converting RPM Packages to ZIP
Why would I convert an RPM to ZIP instead of just extracting it on Linux?
Mainly for sharing with Windows or macOS users, since ZIP opens natively in both operating systems' file managers, while RPM and its underlying cpio payload need a dedicated tool just to browse.
Will the ZIP preserve Unix file permissions from the RPM?
Not reliably. ZIP has an extended attribute field that can hold Unix mode bits, but support varies between tools, so permissions can come through inconsistently or not at all depending on which software did the conversion.
Can I reinstall the package from the ZIP file later?
No. Dependencies, version metadata, and install scriptlets live only in the RPM's Header section, which the conversion never reads — the ZIP holds just the plain files from the Payload.
Is there a single command that converts RPM directly to ZIP?
Not a dedicated one. The documented route is extracting with rpm2cpio and cpio first, then zipping the resulting folder with the zip command or a graphical archiver.
Why did extraction fail on an RPM with very large files inside it?
RPM 4.12 and later use a different, stripped-down cpio format for packages containing files over 4 GB, and older rpm2cpio or cpio builds may not recognize it — updating those tools usually fixes the failure.
Do symbolic links inside the RPM survive as real symlinks in the ZIP?
It depends on the tool. ZIP can technically store symlinks using the same Unix extended attribute mechanism as permission bits, but support for writing and reading that field isn't consistent across every ZIP archiver, so a symlink can end up as a plain text file listing its target instead of a working link.