What Is the INI Format? Simple Config Files Explained

The INI format is a simple, long-standing configuration style built from bracketed sections containing key = value pairs.

INI files are one of the oldest and simplest config formats. You still meet them in git config, Python setup.cfg, tox, and many tools. They are trivial to read, but because there is no single standard, the exact behavior depends on whatever parser is reading the file - a subtlety worth knowing in CI.

What the INI format is

An INI file groups settings into sections, each introduced by a name in square brackets, followed by key = value lines. It is flat and easy to read. There is no nesting beyond one level of sections, which keeps it simple but limits what it can express.

There is no official standard

Unlike TOML or JSON, INI has no formal spec. Parsers disagree on comment characters (semicolon or hash), whether values are quoted, case sensitivity, and how duplicate keys behave. So an INI file that works with one tool can behave differently with another.

INI versus TOML

TOML was designed to be INI done right: same readable section-and-key style, but with a real specification, typed values, arrays, and nested tables. When a project needs INI-like simplicity with predictable parsing, it usually reaches for TOML instead today.

INI in CI and tooling

You meet INI-style files all over the toolchain that CI runs: .gitconfig, Python setup.cfg and tox.ini, flake8 and pytest config, and many linters. In CI you rarely write INI by hand at runtime, but you may template a value into one during a setup step.

An INI-style tox config

# tox.ini consumed by a CI test step
[tox]
envlist = py310,py311

[testenv]
deps = pytest
commands = pytest

Why it persists

INI survives because it is the simplest possible structured config: anyone can read and edit it, and a basic parser is trivial to write. For flat settings where you do not need types or nesting, it is still perfectly serviceable.

Key takeaways

INI files are flat configs of bracketed sections containing key = value pairs.
There is no official standard, so comment syntax, quoting, and case handling vary by parser.
TOML is essentially a standardized, typed successor; INI still lives in git config and Python tooling.