Archive format

RPM converter

A .rpm file is the package format used by Red Hat Enterprise Linux, Fedora, CentOS Stream, openSUSE, and their derivatives. It pairs a binary header of tagged metadata with a compressed cpio archive holding the files to be installed, all sitting behind a fixed 96-byte lead structure.

Private for supported formats — processed in your browser

Convert supported files

Runs on your device

Drop RPM files here

Batch files can each use a different output. Nothing uploads for local conversions.

Working inputs include camera RAW, browser-local audio/video, PDF, CBZ/CBR comics, office documents, ebooks, markup, 3D models, structured text, images, and archives.

Where RPM comes from

Erik Troan and Marc Ewing wrote RPM for Red Hat Linux 2.0 in 1995, replacing the earlier RPP and PMS experiments. Version 3 of the file format standardised the header-plus-cpio layout still in use today. RPM 4 added stronger digests and DSA and RSA signing, and RPM 4.14 introduced zstd payloads to cut installation times on modern hardware.

How RPM works

  • The 96-byte lead is a legacy structure kept for magic-byte identification; the real metadata lives in the two header sections that follow it.
  • The signature header and the main header share one binary layout: a 16-byte structure, a table of 16-byte index entries, and a data store those entries point into.
  • The payload is a cpio archive compressed with gzip, xz, bzip2, or zstd, with member paths recorded relative to the install root.
  • Header tags carry the name, version, release, dependency lists, per-file digests, and the scriptlets run at install and removal time.
  • Because the payload is ordinary cpio, extracting a package never requires the RPM database or any distribution state.

When to use RPM

  • Extracting one file from a package on a machine with no rpm command available.
  • Auditing what a vendor-supplied package contains before it is deployed.
  • Converting a package payload into ZIP or TAR for a build system that cannot read RPM.
  • Recovering files from a package whose distribution is long out of support.

Strengths and limitations

Strengths

  • Rich, queryable metadata is embedded in the file rather than kept only in a repository index.
  • Per-file digests let a package's contents be verified after installation.
  • The cpio payload is a plain, well-documented archive once the headers are skipped.
  • Cryptographic signing is part of the format rather than bolted on by the repository.

Limitations

  • The header format is binary and tag-numbered, so it is unreadable without a tool that knows the tag table.
  • Generic archivers frequently fail on newer payload compressors such as zstd.
  • Installing one properly still requires rpm or dnf to evaluate dependencies and run scriptlets.

Compatibility

rpm, dnf, zypper, and rpm2cpio read the format on every RPM-based distribution, and 7-Zip and libarchive-based utilities extract it on Windows and macOS. Novus Convert skips the lead and both headers in the browser, decompresses the cpio payload, and writes the members out as ZIP or TAR; install scriptlets are never run.

Name, version, release, licence, summary, dependency lists, and per-file digests are stored as header tags. Those tags describe the package rather than its contents, so extraction yields the payload's own paths, modes, and timestamps.