Archive File Formats: ZIP, RAR, 7z, and the Hidden ZIP Family

What an archive format actually is

An archive format solves two distinct problems. First, packaging: turning a tree of many files and folders into a single transferable blob, preserving paths and metadata (permissions, timestamps). Second, compression: encoding the bytes so the result takes less space on disk or less bandwidth over the wire. Some formats do both; some do only one.

The split matters. tar, for example, is purely a packager with no compression. gzip, xz, bzip2, and zstd are purely compressors that operate on a single byte stream. The familiar all-in-one formats (ZIP, RAR, 7z) combine packaging and compression, which is why a single .zip file can hold a folder tree and still be smaller than the original files.

ZIP: the format everything speaks

ZIP was created for PKZIP by Phil Katz in 1989, and it won the format war so thoroughly that it is now the lingua franca of archives. The specification is open (APPNOTE.TXT), every mainstream operating system opens ZIPs natively without third-party software, and it is the default archive choice in Windows Explorer, macOS Finder, and most Linux file managers.

ZIP's compression is decent but not class-leading (typically Deflate). What you trade away in ratio, you get back in reach: a ZIP you create today will open on essentially any device a recipient is likely to own. For sharing, that universality is worth more than the last 10 percent of compression.

ZIP is also the container format for an entire family of specialized file types, covered next.

The big insight: a huge family of files are secretly ZIP

This is the single most useful thing to understand about modern archive file formats. A large number of file extensions that look like their own format are actually ZIP containers with a particular internal layout. The bytes on disk start with the same PK header as any .zip. To read them, you do not need a specialized parser per type — you only need something that understands the ZIP container.

Concrete examples of files that are ZIP under the hood: .apk (Android application packages), .epub (ebooks), .jar, .war, and .aar (Java artifacts), .whl (Python wheel packages), .xpi (legacy Firefox add-ons), .nupkg (NuGet packages), Office OOXML files like .docx, .xlsx, and .pptx, .kmz (Google Earth), .vsdx (Visio drawings), and .crx (Chrome extensions). Each defines its own conventions for what goes inside the ZIP, but the outer shell is plain ZIP.

This is exactly why one in-browser ZIP viewer can open all of them. There is no special reader required for each extension. If you can list entries and extract bytes from a ZIP container, you can peek inside an .apk, an .epub, or a .whl with the same code. For a deep dive on a specific type, see what is an APK file, what is an EPUB file, what is a JAR file, and what is a WHL file.

What is actually inside the ZIP family

The reason these formats all reuse ZIP is that each just layers a small contract on top of the container. Knowing that contract turns a mysterious extension into something you can inspect directly.

An Android .apk holds AndroidManifest.xml (the app's manifest, stored as binary XML), one or more classes.dex files (your compiled Java/Kotlin bytecode in Dalvik format), resources.arsc (the compiled resource table), res/ and assets/ for raw resources, lib/<abi>/*.so for native libraries split by CPU architecture, and META-INF/ carrying the signing manifest and signature blocks. Rename an .apk to .zip and you can browse the whole tree.

An .epub is stricter about layout. The very first entry in the ZIP must be a file named mimetype containing exactly application/epub+zip, and it must be stored uncompressed (no Deflate on that single entry). META-INF/container.xml then points readers to the package document — conventionally OEBPS/content.opf — which holds the metadata, manifest, and spine (reading order). Navigation is toc.ncx in EPUB 2 and a nav.xhtml document in EPUB 3.

A Java .jar mirrors a JVM classpath: compiled .class files sit in directories that match their package names, and META-INF/MANIFEST.MF carries attributes like Main-Class (the entry point for an executable JAR). When a JAR is signed you also find META-INF/*.SF (signature file listing digests of signed entries) alongside *.RSA, *.DSA, or *.EC blocks carrying the cryptographic signature. .war files follow the same rule but arrange their contents into a servlet-container layout (WEB-INF/, WEB-INF/web.xml, WEB-INF/lib/, WEB-INF/classes/).

A Python .whl (wheel) is recognized by its filename, which encodes five tags in a fixed order: {distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl — for example requests-2.31.0-py3-none-any.whl. Inside, the package's importable files sit at the top, and a {name}-{version}.dist-info/ directory holds METADATA (package metadata and dependencies), RECORD (a CSV of every file with its hash and size, used at install time for uninstall and verification), and WHEEL (build metadata such as the generator and tag).

Office OOXML files (.docx, .xlsx, .pptx) are the same idea: a ZIP whose top level always contains [Content_Types].xml, _rels/, and a part directory like word/, xl/, or ppt/ with the document's XML parts and media.

Non-ZIP archive formats

Beyond the ZIP family, a handful of formats cover most remaining use cases.

• RAR — proprietary, developed by RARLAB (Eugene Roshal). Achieves strong compression, especially on multimedia, but the format is not open. Creating RAR generally requires WinRAR; reading RAR is supported by many tools but the decompressor is license-restricted. Use RAR mainly when you must interoperate with someone already sending RAR.
• 7z — open format (LZMA / LZMA2 compression). Frequently produces the best compression ratio of the mainstream options and supports large files and solid archives. The trade-off is that recipients need a 7-Zip-compatible extractor, and extraction can be slower and more memory-hungry.
• tar — the Unix packaging format. tar itself does not compress; it concatenates files into one stream while preserving metadata. On Linux and macOS it is the native way to bundle source trees and software.
• tar.gz and .tgz — a tar archive run through gzip. This is the de facto standard for distributing source code and Unix software. gzip compresses the whole tarball at once (solid compression), which is efficient for many small files.
• gzip, xz, bzip2, zstd — single-stream compressors, not multi-file containers. They compress one file or one tar stream. xz and zstd often give better ratios and (for zstd) far faster decompression than gzip.

How to tell what format a file really is

The file extension is only a hint. It can be renamed, stripped, or wrong. The reliable signal is the magic bytes — the signature at the start of the file. A ZIP-based file begins with the ASCII characters PK (hex 0x50 0x4B), the initials of Phil Katz. If you open an .apk, .epub, .jar, .whl, or .docx in a hex viewer, the first two bytes are 0x50 0x4B.

On the command line, the file(1) utility identifies formats by reading exactly these signatures rather than trusting the extension. Running file some-download will report something like Zip archive data even when the extension is .jar or .xlsx. That is the fastest way to confirm that a mystery file belongs to the ZIP family. RAR files start with Rar!, 7z files with 7z (0x37 0x7A, plus BC AF 27 1C), gzip with 0x1F 0x8B, and tar archives carry the ustar magic string at byte offset 257.

Choosing an archive format

There is no single best format — there is the right format for a given recipient and goal.

• ZIP when you need maximum compatibility. If a non-technical person might open it, or it will cross operating systems, ZIP is the safe default. Everything opens it.
• 7z when compression ratio matters more than reach: large backups, software distributions where you can assume the recipient has a 7-Zip tool, or when you want solid archives across many small files.
• tar.gz on Linux, Unix, and macOS, and for source-code bundles. It preserves Unix permissions and is what package managers and build tooling expect.
• RAR only when interoperating with someone who sends or requires RAR. Otherwise the open formats cover the same ground without the licensing constraints.

How to open or inspect any archive

The standard options, in increasing order of control: use the operating system's built-in handler (Windows Explorer for ZIP, macOS Archive Utility for ZIP and some others), the command line (unzip for ZIP, tar -xzf for tar.gz, 7z x for 7z and many other formats), or a dedicated tool when you need to look inside without extracting.

For anything in the ZIP family, an in-browser viewer lets you browse the file tree, search, and preview contents — code with syntax highlighting, images, audio, video, and PDFs — without writing anything to disk. Because nothing is uploaded, this is useful for sensitive archives: the file is parsed locally in the page, and once loaded it works with the network off. That said, client-side parsing does not make a malicious file harmless; it only means your file contents are not sent to a server. For more on what local processing does and does not guarantee, see security and privacy.

When you want to try it, the tool opens any ZIP or ZIP-based archive (.apk, .epub, .jar, .whl, .docx, and the rest) directly in your browser.

Frequently asked questions