A format by convention
An INI file is about as simple as configuration gets: a section name in square brackets opens a group, and beneath it each setting is written as a name, an equals sign and a value, one per line. Lines beginning with a semicolon — or, in some dialects, a hash — are comments. That is essentially the whole format, which is exactly why it spread so widely; almost anyone can read or edit one, and almost any language can parse it in a few lines of code. Windows leaned on INI files heavily before the registry, and the basic shape lives on in the configuration of editors, servers, desktop environments and the section-and-key style of Git configuration.
The catch is that INI was never standardised. Because no authority ever defined it, implementations disagree on the awkward questions: whether section names can nest, whether keys are case-sensitive, whether values may be quoted, how comments are marked, and whether a key may appear more than once. A file that one program reads happily may confuse another. In practice this is manageable as long as you keep to the simple, widely understood core and avoid the contested corners.
Strengths
- Extremely simple to read, write and parse.
- Familiar after decades of use across Windows and many applications.
- Comments and grouped sections make small configurations tidy.
- Trivial to edit by hand with any text editor.
Limitations
- No formal specification, so dialects disagree on the details.
- Flat by nature — nesting beyond sections is not standardised.
- Values are untyped text, leaving interpretation to the application.
- Quoting, comment markers and duplicate keys vary between parsers.
When to use INI
Use INI for small, flat configuration where a couple of grouped sections of key-and-value pairs is all you need and human editing should stay effortless.
INI FAQ
- What is the difference between INI and TOML?
- TOML can be seen as INI’s stricter descendant: it keeps the bracketed-section, key-and-value feel but adds a formal specification, explicit types and proper support for nesting and arrays. INI is looser and dialect-dependent, which is fine for simple needs but unreliable for complex ones.
- Why does my INI file work in one program but not another?
- Because INI has no single standard, parsers differ over things like case sensitivity, quoting and comment characters. A feature one application allows another may reject, so stick to the plain core — bracketed sections and simple key-and-value lines — for the best portability.
- Can Morphr convert an INI file to JSON?
- Yes. Morphr reads the sections and key-value pairs locally and maps them to a structured target such as JSON or YAML, with each section becoming a nested object. Since INI values are plain text, anything that needs a specific type is carried across as a string unless context makes it clearer.