The INI file is a plain-text configuration format built from named sections, each containing simple key/value pairs. A section header appears in square brackets, such as “[display]”, and is followed by lines of the form “key=value”. Comments are typically introduced with a semicolon. The format’s appeal is its sheer simplicity: it is trivial to read by eye, trivial to edit by hand, and trivial to parse with a few lines of code.
INI files rose to prominence in the MS-DOS and early Windows era, where files like WIN.INI and SYSTEM.INI held system and application settings. Windows exposed a dedicated API for reading and writing these “initialization files,” including the GetPrivateProfileString function documented by Microsoft. That documentation describes how the call “retrieves a string from the specified section in an initialization file,” using an application (section) name, a key name, a default value, and a file name, which directly reflects the section/key/value structure that defines the format.
Notably, Microsoft’s own documentation marks these profile functions as legacy. It states that the functions are “provided only for compatibility with 16-bit Windows-based applications” and advises that applications “should store initialization information in the registry” instead. The Windows Registry was introduced as the strategic replacement for scattered INI files, yet INI never disappeared; it remained popular precisely because it is human-readable and version-control-friendly in ways the binary registry is not.
There has never been a single authoritative INI standard, which means the format is really a family of dialects rather than one specification. Implementations disagree on whether keys are case-sensitive, whether values may be quoted, how to handle duplicate keys, whether sections may be nested or repeated, whether the hash sign as well as the semicolon introduces comments, and how to represent multi-line values. The Windows API defines one concrete behavior, but other tools and libraries each codify their own variations.
This informality is both INI’s weakness and the reason newer formats exist. TOML was designed in part to give INI-style configuration a precise specification and a richer type system, while the Java properties file format addressed similar needs in the Java world with carefully defined escaping rules. Even so, INI-style files remain common across desktop applications, Python’s configparser, Git configuration, and systemd unit files, a testament to how far a format this minimal can travel.