RAR (4.x) file format
A RAR archive using the RAR 1.5-4.x format.
- MIME type
- application/x-rar-compressed
- Extensions
- .rar
- Category
- Archives & compression
Magic-number signature
| 0x00000000 | 526172211A0700 | Rar!··· | 'Rar!' RAR4 signature |
About the RAR (4.x) format
RAR 4.x is the legacy WinRAR format, produced by WinRAR 1.5 through 4.20 and still emitted today by anything asked for maximum compatibility. Everything in the file is a block, and every block starts with the same four fields — a 16-bit CRC, a one-byte type, 16 bits of flags and a 16-bit size — which is why the seven-byte marker at offset 0 is itself a block rather than a bare magic number. The archive is proprietary: the decompressor is published, the compressor is not, so free tools can read RAR 4 but cannot write it.
Header layout, byte by byte
| Offset | Length | Field | Meaning |
|---|---|---|---|
| 0 | 7 | Marker block (MARK_HEAD) | Always 52 61 72 21 1A 07 00, which reads as 'Rar!' followed by 1A 07 00. It is not a bare magic number but a regular RAR block that happens to have constant contents: HEAD_CRC 0x6152, HEAD_TYPE 0x72, HEAD_FLAGS 0x1A21, HEAD_SIZE 0x0007. RAR5 keeps the first six bytes and appends 01 00, so the byte at offset 6 is the whole difference between the two generations. |
| 7 | 2 | Archive header CRC (HEAD_CRC) | Low 16 bits of a CRC-32 taken over the rest of this block. Every RAR block carries one, so a hex editor can localise damage to a single block instead of condemning the whole archive. |
| 9 | 1 | Archive header type (HEAD_TYPE) | 0x73 marks MAIN_HEAD, the archive-wide header. The other types you will meet are 0x74 for a file, 0x75 for a comment, 0x7A for a subblock and 0x7B for the end-of-archive marker. |
| 10 | 2 | Archive header flags (HEAD_FLAGS) | Little-endian bit field. 0x0001 says this is one volume of a set, 0x0002 that an archive comment is stored inline, 0x0004 that the archive is locked against modification, 0x0008 solid, 0x0010 the newer name.partN.rar volume naming, 0x0040 a recovery record is present, 0x0080 that the block headers themselves are encrypted, 0x0100 that this is the first volume. |
| 12 | 2 | Archive header size (HEAD_SIZE) | Total length of this block including the six bytes already read. The plain case is 0x000D, thirteen bytes, so the next block begins at offset 20; an inline comment or an authenticity record makes it larger and pushes everything after it back. |
| 14 | 2 | RESERVED1 | Reserved, written as zero by every released version. Historically it held a high-word volume number in very old builds. |
| 16 | 4 | RESERVED2 | Reserved, written as zero. Four bytes of padding that keep the archive header at its familiar thirteen-byte length. |
| 20 | 2 | First file header CRC | Start of the first FILE_HEAD block — but only when the archive header above was the minimum thirteen bytes. Read HEAD_SIZE at offset 12 and add it to 7 rather than trusting 20 blindly; every offset in the rows below inherits the same assumption. |
| 22 | 1 | File header type (HEAD_TYPE) | 0x74. If you see 0x7B here instead the archive is empty, because that is the end-of-archive block. |
| 23 | 2 | File header flags | 0x0001 means the file continues from the previous volume, 0x0002 that it continues into the next, 0x0004 that it is password protected, 0x0100 that the 64-bit high size words are present, 0x0200 that the name is stored as UTF-16 as well as in the local code page, 0x0400 that an eight-byte salt follows the name. |
| 25 | 2 | File header size (HEAD_SIZE) | Length of this whole header, which is 32 bytes of fixed fields plus the name and any optional salt or extended timestamp. Compressed data begins immediately after it. |
| 27 | 4 | PACK_SIZE | Compressed byte count of this entry, low 32 bits. Files over 4 GiB carry the high word separately, right after the ATTR field, and only when flag 0x0100 is set. |
| 31 | 4 | UNP_SIZE | Original byte count, low 32 bits, with the same 4 GiB escape hatch. A solid archive still records a real value here even though the entry cannot be decompressed on its own. |
| 35 | 1 | HOST_OS | The system that created the entry: 0 MS-DOS, 1 OS/2, 2 Windows, 3 Unix, 4 Mac OS, 5 BeOS. It decides how the four attribute bytes further down are to be read. |
| 36 | 4 | FILE_CRC | CRC-32 of the uncompressed contents. This is the number behind every 'checksum error' WinRAR reports, and the one a recovery record is meant to let you repair. |
| 40 | 4 | FTIME | MS-DOS packed date and time: seven bits of year counted from 1980, four of month, five of day, then five of hour, six of minute and five of a two-second tick. No time zone, two-second resolution, nothing before 1980. |
| 44 | 1 | UNP_VER | Minimum unpacker version times ten. 20 means the 2.0 algorithm, 29 the 2.9 one used by WinRAR 3.x and 4.x. A modern extractor implements all of them; the byte matters when an old tool refuses the file. |
| 45 | 1 | METHOD | 0x30 stored, 0x31 fastest, 0x32 fast, 0x33 normal, 0x34 good, 0x35 best. A 0x30 entry can be carved out of a damaged archive by hand because the bytes after the header are the file itself. |
| 46 | 2 | NAME_SIZE | Byte length of the name that follows the fixed fields. When flag 0x0200 is set this run holds the local-code-page name, a zero byte and then a compressed UTF-16 form of the same name. |
| 48 | 4 | ATTR | File attributes, interpreted according to HOST_OS: DOS attribute bits on Windows, a Unix mode word on Unix. The directory bit here is how RAR marks a folder entry, which has no data at all. |
| 52 | variable | FILE_NAME | NAME_SIZE bytes of path, using backslashes rather than forward slashes. An entry whose name starts with a drive letter or contains .. is a path-traversal attempt and any sane extractor rejects it. |
Telling it apart from its neighbours
| Easily confused with | How to tell |
|---|---|
| RAR5 | The two generations share six bytes and diverge on the seventh. RAR 4 is 52 61 72 21 1A 07 00, seven bytes; RAR 5 is 52 61 72 21 1A 07 01 00, eight. Both use the .rar extension and both come from WinRAR, so the byte at offset 6 is the only thing separating an archive a 2005 tool can open from one it cannot. Inside, RAR 5 replaced the whole block layout with variable-length integers, so nothing below the marker transfers between them. |
| ZIP | Nothing subtle at byte level — 52 61 72 21 against 50 4B 03 04 — but the two are confused constantly because both are 'a compressed folder'. The structural difference matters more: a ZIP keeps its directory at the end and can be listed from the last few hundred bytes, while a RAR walks a chain of blocks from the front, so a RAR truncated at the tail still lists correctly and a ZIP does not. |
| 7-Zip | 7-Zip archives open 37 7A BC AF 27 1C. Both formats offer solid compression and strong encryption, and 7-Zip the application writes both, which is where the confusion starts. The .7z format is open and freely implementable; RAR compression is not, so a tool that can create .7z cannot necessarily create .rar. |
| Self-extracting RAR | An SFX archive is a Windows executable with the RAR data appended, so offset 0 reads 4D 5A ('MZ') and the 'Rar!' marker turns up thousands of bytes later. It is still a perfectly valid archive: point a real extractor at it and it scans forward for the marker rather than insisting on offset 0. |
How these files break
- One volume of a multi-volume set is missing. Each part is a well-formed RAR in its own right, so a hex dump shows an intact marker and clean block CRCs, and extraction still fails because an entry flagged 0x0002 continues into a part that is not there. The tell is flag bit 0x0001 in the archive header at offset 10 with a gap in the .partN.rar numbering.
- Truncated download. RAR walks blocks forward from offset 7, so everything up to the cut extracts normally and the failure appears only on the last entry. Where a recovery record is present — archive header flag 0x0040 — WinRAR can rebuild a surprising amount of what was lost, which is the one real advantage RAR has kept over ZIP.
- Text-mode transfer. An FTP client in ASCII mode rewrites every 0D 0A inside the compressed stream, which leaves the marker and every header offset untouched. The archive lists perfectly and then fails on FILE_CRC at offset 36 for each entry, which is exactly the symptom people mistake for a bad password.
- Encrypted headers mistaken for damage. With -hp the block headers themselves are encrypted, so a hex dump past offset 20 is noise and file names never appear. Archive header flag 0x0080 at offset 10 is what distinguishes this from real corruption, and it is set on an archive that is perfectly intact.
- A single flipped byte in a block header. Because HEAD_SIZE at offset 25 tells the reader where the next block starts, damage to that field does not corrupt one entry — it derails the walk and every block after it is read from the wrong place. The 16-bit HEAD_CRC is what catches it before the reader wanders off.
Where the format stands today
RAR 4 is a legacy format kept alive by inertia and by one genuine technical advantage. The inertia is the larger half: scene releases, older backup sets and a great deal of material posted between 1998 and 2012 are RAR 4 multi-volume sets, and none of it is going to be repacked. The advantage is the recovery record, which lets an archive survive real bit rot on optical media or a flaky transfer in a way that ZIP, 7z and tar.gz simply cannot. For new archives it has lost on every other axis: 7-Zip and Zstandard compress better and are open, and RAR compression remains proprietary, so a build pipeline that emits .rar has locked itself to one vendor's tool. RAR 5 superseded it in 2013 with 64-bit sizes, better encryption and faster recovery records, and WinRAR now writes RAR 5 by default — RAR 4 is what you select deliberately when the recipient's extractor is old.
Open RAR (4.x) files on this site
Every one of these runs in your browser — the file never leaves your machine.
Related formats
Formats that are easy to confuse with RAR (4.x) — compare their leading bytes.