Windows .reg File Syntax and Structure Explained

When the Windows Registry Editor (regedit.exe) exports registry data, it generates a plain-text configuration file with a .reg extension. This article breaks down the precise structural syntax used in these files, covering the mandatory file headers, key path declarations, data typing rules, value formatting, and deletion syntax.

1. The File Header

Every .reg file begins with a mandatory version header on the very first line, followed immediately by a blank line.

Modern Systems (Windows 2000 through Windows 11):
```
Windows Registry Editor Version 5.00
```
This indicates a Unicode-encoded file format capable of handling standard and extended character sets.
Legacy Systems (Windows 95/98/NT 4.0):
```
REGEDIT4
```
This indicates ANSI encoding.

If the header is missing or altered, Windows Registry Editor will reject the file with an error.

2. Registry Key Paths

Registry keys define the hierarchical container where settings reside. In a .reg file, key paths are enclosed in square brackets [ and ], placed on their own line:

[HKEY_LOCAL_MACHINE\SOFTWARE\ExampleApp]

Key paths must use the full root key name rather than abbreviations: * HKEY_LOCAL_MACHINE (not HKLM) * HKEY_CURRENT_USER (not HKCU) * HKEY_CLASSES_ROOT (not HKCR) * HKEY_USERS (not HKU) * HKEY_CURRENT_CONFIG (not HKCC)

Each key section applies to all value entries listed beneath it until another bracketed key path appears. Key definitions are separated from value declarations by a line break.

3. Registry Values and Data Formats

Values within a key follow the syntax "ValueName"=Type:ValueData.

String Values (`REG_SZ`)

String names and their string values are wrapped in double quotation marks. Any literal double quotation marks (") or backslashes (\) inside the string data must be escaped using a backslash (\" and \\).

"AppPath"="C:\\Program Files\\ExampleApp\\app.exe"

The Default (Unnamed) Value

The default value of a key does not use quotation marks for the name; instead, it is designated by the @ symbol:

@="Default application data"

DWORD Values (`REG_DWORD`)

32-bit integer values use the dword: prefix followed by an 8-character hexadecimal number:

"Enabled"=dword:00000001
"Timeout"=dword:0000003c

QWORD Values (`REG_QWORD`)

64-bit integer values are exported using the hex(b): prefix followed by eight comma-separated hex bytes in little-endian order:

"LargeValue"=hex(b):00,e4,0b,54,02,00,00,00

Binary Values (`REG_BINARY`)

Raw binary data is represented with the hex: prefix followed by comma-separated, two-digit hexadecimal bytes:

"BinaryData"=hex:01,a4,00,ff,2b

Extended Data Types

Special registry types map to specific numeric identifiers appended to the hex keyword, containing byte sequences in UTF-16LE encoding: * Expandable String (REG_EXPAND_SZ): hex(2): * Multi-String (REG_MULTI_SZ): hex(7):

"SystemPath"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,00,25,00,00,00

4. Multi-Line Data and Line Continuation

When binary or hex-encoded string data exceeds standard line lengths, Regedit splits the data across multiple lines using a trailing backslash (\) as a line-continuation character:

"MultiLineBinary"=hex:41,00,70,00,70,00,6c,00,69,00,63,00,61,00,74,00,\
  69,00,6f,00,6e,00,00,00

The next line begins with two spaces before the remaining bytes continue.

5. Deletion Syntax

Regedit supports removal of keys and values using a hyphen (-):

To delete a key and all its subkeys: Place a hyphen inside the opening bracket before the key path:
```
[-HKEY_CURRENT_USER\SOFTWARE\ExampleApp]
```
To delete a specific value: Set the value data to a single hyphen:
```
"ObsoleteSetting"=-
```
To delete the default value: Set @ to a hyphen:
```
@=-
```

6. Comments and Whitespace

Lines beginning with a semicolon (;) are treated as comments and ignored by Regedit during import operations:

; This is a comment describing the configuration below
[HKEY_CURRENT_USER\SOFTWARE\ExampleApp]
"Configured"=dword:00000001

A blank line is required at the end of the .reg file to guarantee that the final instruction parses correctly upon execution.