PAR File Documentation

Summary

A PAR (Parchive) file is a parity/recovery file used to verify and repair a set of other files, most famously multi-part downloads from Usenet. The original .par is a PAR1 index volume; it was superseded by the far more capable .par2. You do not open a .par like a document — you feed it, alongside the files it protects, to a Parchive tool such as MultiPar or QuickPar, which uses its Reed–Solomon parity data to reconstruct any missing or corrupted parts. (The same extension is also used by Siemens Solid Edge for a 3D CAD part.)

Technical details

Feature	Value
Full name	Parchive (Parity Volume Set) file
File extension	`.par` (PAR1); successor `.par2`
MIME type	`application/octet-stream`
Format type	Error-correction / parity recovery data
Error-correction code	Reed–Solomon over a Galois field
Developer	Parchive project (open specification)
Introduced	PAR1 in 2001; PAR2 (Parity Volume Set Specification 2.0) in 2003
Specification	Parity Volume Set Specification 2.0
Open standard	Yes — publicly published specification
Byte order	Little-endian
PAR1 magic	`PAR\0` (`50 41 52 00`)
PAR2 packet magic	`50 41 52 32 00 50 4B 54` (`PAR2\0PKT`)
PAR2 structure	Independent 64-byte-header packets with MD5 hashes
Typical use	Repairing multi-part Usenet / split archive downloads
Tools	MultiPar, QuickPar, par2cmdline
Related extensions	`.par2`, `.002`, `.rar`, `.nzb`, `.sfv`
Other meaning	Siemens Solid Edge 3D CAD part
Specification URL	`parchive.github.io/doc/Parity Volume Set Specification v2.0.html`

File signature (magic bytes)

50 41 52 32 00 50 4B 54

This is the PAR2 packet magic PAR2\0PKT, which begins every packet in a modern Parchive file (a .par2, and any of its .vol recovery volumes). It appears at the very start of the file and again at the head of each subsequent packet, since a PAR2 file is a concatenation of self-contained packets. The original PAR1 .par instead starts with the 4-byte magic PAR\0 (50 41 52 00). A Solid Edge CAD .par has no stable public signature and is identified by context, not magic bytes.

What is a PAR file?

A .par file is a Parchive file: parity data that verifies and repairs a set of other files. Parchive (short for “parity archive”) was created in 2001 to solve a specific problem on Usenet, where a large binary is split into many parts and posted, and individual parts routinely arrive missing or corrupted. Instead of re-downloading the whole thing, you download the accompanying Parchive files: a tool reads their error-correction data and rebuilds the damaged or absent parts from what survived. The original format is PAR1, whose .par file is the index volume that names and hashes the protected files. PAR1 was quickly superseded by PAR2 (the Parity Volume Set Specification 2.0, 2003), which fixed PAR1’s limitations and is what almost everything uses today under the .par2 extension.

A Parchive file is not something you “open” to view content. It is input to a recovery tool — MultiPar, QuickPar or the command-line par2cmdline — that you point at the protected files plus their .par/.par2 set. The tool verifies each file against stored hashes, reports what is damaged, and if enough recovery data is present, reconstructs the rest. The mechanism underneath is Reed–Solomon erasure coding, the same class of code used on CDs, in RAID and in QR codes. The sections below explain how the format encodes that, packet by packet. (A second, unrelated meaning of .par — a Siemens Solid Edge 3D CAD part — is covered near the end.)

Reed–Solomon recovery: blocks, not files

Parchive does not work on whole files; it works on fixed-size blocks. The protected data is divided into equal-size input blocks (the block size is recorded in the file), and Parchive computes recovery blocks from them using Reed–Solomon arithmetic over a Galois field. The defining property of this coding is that any input blocks lost can be reconstructed as long as you hold at least as many recovery blocks as the number of blocks missing. If 12 blocks across your download are damaged and you have 12 or more recovery blocks, the original is fully recoverable; the recovery blocks are interchangeable, so it does not matter which input blocks were lost.

This block-level design is why PAR2 is packaged as a main .par2 file plus a series of .vol000+01.par2, .vol001+02.par2 and similar volumes. The number after the + is how many recovery blocks that volume contains. You download only as many volumes as you need to cover the damage: a lightly corrupted set needs one small volume, a badly damaged one needs several. PAR1, by contrast, operated per file rather than per block, so one bad byte cost a whole recovery file — a major reason it was replaced.

The PAR2 packet: 64-byte header, MD5 hashing and self-synchronisation

A PAR2 file is a flat concatenation of independent packets. Each packet is self-describing and self-verifying, which lets a reader recover the structure even from a partially corrupted .par2 file. Every packet starts with the same 64-byte header:

PAR2 packet header (64 bytes, little-endian)
offset size field
  0     8   magic          "PAR2\0PKT" (50 41 52 32 00 50 4B 54)
  8     8   packet length  total bytes incl. this 64-byte header (multiple of 4)
 16    16   packet MD5      MD5 of everything after this field
                           (from setId through the packet body)
 32    16   recovery set ID identifies which file set this packet belongs to
 48    16   packet type     16 ASCII bytes, e.g. "PAR 2.0\0Main\0\0\0\0"
 64    ..   packet body     type-specific data

Two design choices make the format robust. First, the magic string repeats at the head of every packet, so if a reader loses its place in a damaged file it can resynchronise simply by scanning forward for the next PAR2\0PKT. Second, the 16-byte packet MD5 at offset 16 covers the rest of the packet, so any packet can be individually validated and a corrupt one discarded without invalidating the others. The recovery set ID ties every packet to one protected file set, and because packets are commonly duplicated across the volumes, a reader can collect the critical ones (like the main and file-description packets) from whichever volume happens to be intact.

The main, file-description, checksum and recovery packets

The packet type field selects what the body contains. A handful of types do all the work:

Packet type	Contents
`PAR 2.0\0Main`	The slice (block) size and the list of File IDs in the recovery set, defining the whole set
`PAR 2.0\0FileDesc`	One per file: its File ID, name, length, full MD5 and the MD5 of its first 16 KB
`PAR 2.0\0IFSC`	Input File Slice Checksums: an MD5 and CRC-32 for every block of a file
`PAR 2.0\0RecvSlic`	One recovery block, tagged with its exponent in the Reed–Solomon matrix
`PAR 2.0\0Creator`	Free text naming the program that made the set

Verification and repair follow directly from these. The main packet establishes the block size and which files belong together. The file-description packets give each file’s expected name, size and MD5, letting the tool spot a missing or renamed file. The Input File Slice Checksum packets carry an MD5 and a CRC-32 for every block, so the tool can locate damage down to the individual block and even find data that has been shifted within a file. When blocks are found bad, the tool pulls recovery slice packets — each one recovery block plus the exponent identifying its row in the Reed–Solomon matrix — and solves the linear system to regenerate the missing input blocks. If it has enough recovery blocks, the repair succeeds exactly; if not, it reports precisely how many more are needed.

Why .par (PAR1) gave way to .par2

The plain .par extension belongs to PAR1, and encountering one today usually means an old archive. PAR1 had structural limits that PAR2 removed: it recovered whole files rather than blocks (so any damage to a file could require a full recovery file for it), it capped the number of files it could protect, and it handled large or oddly-split sets poorly. PAR2 switched to the block-based Reed–Solomon scheme, the self-synchronising packet layout above, and MD5 hashing throughout, which together let it protect thousands of files, repair partial damage efficiently, and validate itself when corrupted. Modern tools still read PAR1 for compatibility, but they create PAR2. If you are generating recovery data now, use .par2; the bare .par is essentially legacy.

The other .par: a Solid Edge CAD part

Confusingly, .par is also the extension for a Solid Edge Part, a 3D CAD file from Siemens Solid Edge. That kind of .par holds a single mechanical part: its solid (boundary-representation) geometry, the ordered feature tree that builds the part parametrically, and metadata such as material and a preview thumbnail. It has nothing to do with parity or recovery, and no reliable magic signature across versions, so you identify it by context — it travels with engineering projects alongside Solid Edge assemblies (.asm) and drawings (.dft). You view it for free with the Siemens Solid Edge Viewer or edit it in Solid Edge, and to move the geometry into another CAD program you export it to the neutral STEP format. If a “PAR” file sits next to CAD data rather than a split download, it is this format, not Parchive.

Frequently asked questions

How do I “open” a PAR2 file?

You do not open it for viewing; you use it to repair a download. Put the .par2 set in the same folder as the files it protects and open it with MultiPar, QuickPar or par2cmdline. The tool verifies every file against the stored hashes and, if any blocks are damaged or missing, reconstructs them from the recovery volumes. You only need to download as many .vol volumes as there are damaged blocks.

How many recovery blocks do I need to repair a set?

At least as many recovery blocks as the number of input blocks that are missing or corrupted. Reed–Solomon makes the recovery blocks interchangeable, so it does not matter which input blocks were lost — only the count matters. Each PAR2 volume’s filename shows its block count after the +, so you can add volumes until you have enough.

Why does every PAR2 packet repeat the “PAR2\0PKT” magic?

So a reader can recover from corruption. Because the 8-byte magic marks the start of every packet, a tool that hits damaged bytes can scan forward for the next magic and resume, and each packet’s own MD5 lets it validate or discard packets individually. That self-synchronising, self-verifying layout is what lets PAR2 repair even a partly damaged .par2 file.

References

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.

Table of contents