this also works in some parsers

The equals sign separates the key from the value. Whitespace around it is usually ignored. Comments start with a semicolon or, in some variants, a hash symbol. This loose convention means you can annotate a file without breaking it.
Section and key names are often case-insensitive, but that behavior depends on the reader. A conservative approach is to treat them as case-sensitive and keep consistent casing throughout the file. Some parsers allow line continuation with a trailing backslash, yet this is far from universal, so multi-line values are best avoided.
A Short Background
The style became widespread with MS-DOS and early Windows. System files such as config.sys and later win.ini, system.ini held system and application preferences. Microsoft even provided dedicated API calls like GetPrivateProfileString to read and write these files. Those functions are now largely deprecated, but they cemented the format’s place in software history.
Because the format was easy to read and modify, third-party developers adopted it for their own software. Over time, the registry and XML took over many Windows duties, but the ini approach had already escaped the ecosystem. Today you will find .ini files on Linux servers, inside Python packages, and bundled with open-source games.
Editing Without Breaking Things
Manual editing is one of the format’s strengths, but it comes with caveats. Always keep a backup before changing values. A typo in a section header or an unclosed bracket can make the whole file unreadable to the application.
Most parsers expect either ANSI or UTF-8 text. If you save a file with a byte-order mark or a rare encoding, an old reader might choke. Line endings are another subtle issue: Windows CRLF versus Unix LF rarely causes problems, but some strict parsers treat them differently.
When you modify a value, respect the expected type. Writing "true" where the program wants "1" may or may not work. Since ini does not enforce types, the application decides how to interpret the string. If a setting seems ignored after an edit, check whether the program recreated a default file on launch, overwriting your changes.
Working With INI Programmatically
Nearly every programming language has a library for reading these files. Python’s configparser module is a standard example. It treats sections as dictionaries and lets you fetch values with defaults:
import configparser
cfg = configparser.ConfigParser()
cfg.read('app.ini')
timeout = cfg.getint('network', 'port', fallback=80)
The same module supports interpolation, where a value can reference another key with syntax like %(home)s. Similar tools exist for C++, Java, Go, and Rust. The libraries differ in how they handle duplicate keys, case sensitivity, and missing sections. If you are writing a parser yourself, decide these rules upfront; the original spec is silent on many edge cases.
Why Developers Still Choose It
The main appeal is transparency. A user can fix a misconfiguration by editing a file, no special tool required. There is no nesting syntax to learn, no significant whitespace, and no curly braces. For a small project, that lowers the barrier for contribution.
Startup time is another factor. Reading a few kilobytes of key-value pairs is trivially fast. You don’t need a full JSON or XML parser if your settings fit on a screen. The files also diff cleanly in version control, making them friendly to collaborative projects.
Where INI Falls Short
The same simplicity becomes a limitation as needs grow. There is no standard way to represent lists, maps, or hierarchical data. You can fake a list by comma-separating values, but then you must agree on escaping rules for commas inside items.
Type handling is left entirely to the application. A value like "0x1F" might be hex to one program and a string to another. Booleans are especially messy: "yes", "on", "true", "1" all appear in the wild.
Because no official specification exists, interoperability can suffer. One parser might treat duplicate sections as an error; another might merge them. A file written by a liberal writer could be rejected by a strict reader. Additionally, there is no way to embed binary data or comments within a value, which limits expressive documentation.
Modern Alternatives
Formats such as JSON, YAML, and TOML address these gaps. TOML in particular started as a stricter, more predictable cousin of the ini file, adding explicit types and nested tables while keeping the section/key familiar feel. JSON dominates web APIs and enterprise config, though its brace-heavy style is less pleasant to hand-edit. YAML finds a home in DevOps pipelines, despite indentation rules that trip up newcomers.
Still, for a desktop utility that needs a single file to store a window position and a recent file list, reaching for those heavier formats is overkill.
Practical Tips for Daily Use
When you receive an ini file from a vendor, skim the section names first. They usually mirror the application’s UI tabs or modules. Change one setting at a time and reload the app to confirm the effect. If something breaks, deleting the file often forces the software to regenerate a default version—handy for resetting stuck preferences.
If you are distributing your own software, document the keys you support. Users should not have to guess whether "loglevel" accepts "debug" or "3". A small comment block at the top of the file goes a long way.
Security-wise, remember that ini files are not encrypted. Storing passwords in plain text is a bad idea even if the file sits in a user directory. Use environment variables or a dedicated secrets store for anything sensitive.
A Format That Knows Its Place
The ini file will not win any awards for expressive power. It does not try to be a data interchange language or a programming construct. Instead, it remains a straightforward notebook where a program jots down its preferences.
That modest role is exactly why it survives. As long as there are developers who value a config file you can edit with a bare text editor, the humble .ini will keep showing up in project folders.