INI vs JSON vs XML vs Others for the best config file format

INI

As mentioned above, the INI file format is the oldest and probably the most used today.

This gained popularity with Windows 3.x and is still used in Python and PHP projects, as well as many legacy systems.

The reason is simple: INI files are extremely simple and human readable, as they don’t need special tools to read or write, and many languages and frameworks provide direct native support to work with them, making them ideal for the non-technical users who only need to edit one.

Here is an example of how an INI file looks:

[database]
host = localhost
port = 5432
name = myapp_db
[server]
debug = true
port = 8080

You can see that it is actually very simple to understand. The section is between brackets (“[“,”]”), and you have the values defined under it.

In the example above, we can see that the [database] section contains three values for host, port, and name, while the [server] section refers to the port that will be used and whether or not we plan to debug the communication.

You can easily change this in Notepad, and the change will be reflected automatically in the application.

Of course, as technology advanced, new ideas were implemented, such as nested data, arrays, or different data types. This is one of the cons of the INI structure, as it doesn’t support any of the previously mentioned features. Also, INI structures are regarded as unsuitable for complex, hierarchical configurations.

We can consider INI structures ideal for small to medium apps, legacy systems, embedded tools, and user-facing settings files.

JSON

JavaScript Object Notation, or JSON for short, is arguably the most popular configuration file format in modern development.

One of the reasons is that JSON is almost everywhere these days. You can find it in APIs and data exchange structures. Files like package.json, tsconfig.json, and .eslintrc have made JSON the primary language for project configuration.

If we take the same example from INI and convert it to JSON, it would look like this:

{
  "database": {
    "host": "localhost",
    "port": 5432,
    "name": "myapp_db"
  },
  "server": {
    "debug": true,
    "port": 8080
  }
}

Of course, being native in Javascript means that it can be parsed in almost any language that you can imagine. In contrast to INI files, it also supports nested structures and types of values.

With widespread familiarity in the industry, nearly every developer knows what a JSON file is and has also brought another advantage, which is extensive tooling support. Validators, formatters, schema validators, and so on, all of which are available and ready to use.

Now, just because it is popular, it doesn’t mean that it's perfect. JSON file types also have some limitations, such as the lack of support for comments, which can be a major pain point if we deal with a large configuration file.

Looking at the structure, you may notice that it is strict. Trailing commas will break parsing, and if the file is too large, it can become verbose and hard to scan for deeply nested configs.

While it is human readable and writable, you can’t argue that it is the most pleasant file format to write by hand, and it will cause some headaches in the process.

Nowadays, JSON is best known for web projects, Node.js ecosystems, APIs, and machine-generated or heavily tooled configurations. This is where it shines.

When moving from INI to JSON, the main challenge is mapping sections to top-level objects and handling type coercion. INI stores everything as strings, while JSON lets you use native types like integers and booleans. A simple script or library (like Python's configparser + json.dump) can automate most of it.

XML

The XML file type was once the undisputed king of configuration file formats in enterprise environments, and it continues to be widely used today.

For example, MSIX includes the appxmanifest.xml file, and the Android manifest is also an XML file (AndroidManifest.xml).

Although it is an old format, it was specifically designed for large-scale scenarios, which is why it is popular today. It is extremely expressive and supports attributes, namespaces, schemas, and transformations. Due to its age, you can find excellent validators, editors, diff tools, and transformers out there.

By the way, remember how the inability to write comments was a pain point in JSON files? Guess what? XML files support it natively!

However, unlike INI and JSON files, it is quite difficult to read. Take a look at the following example in XML file format:

<config>
  <database>
    <host>localhost</host>
    <port>5432</port>
    <name>myapp_db</name>
  </database>
  <server>
    <debug>true</debug>
    <port>8080</port>
  </server>
</config>

It hurts your eyes a little, doesn’t it?

Unfortunately, this is a difficult type to read and write by hand, especially for large configurations. It appears to be very verbose and contains far more boilerplate than any other format.

This makes it a complete nightmare and overkill for simple key-value scenarios, not to mention that parsing is more difficult than JSON files.

Today, it is most commonly used in Java ecosystems, legacy systems, document-centric configurations, and scenarios requiring formal schema validation. Of course, large enterprise applications will definitely continue to use XML files due to their usual presence on large infrastructures.

YAML

YAML was designed specifically to be readable by humans and has since become the main config file format in DevOps and cloud infrastructures.

If you want examples of where this is used, we can consider Docker Compose, Kubernetes, GitHub actions and Ansible. It is a clean, indentation-based syntax that is actually very close to plain English.

Oh, and did we mention that this supports comments natively? It not only supports anchors and aliases, but it can also hold rich type systems such as strings, numbers, booleans, nulls, lists, maps, and multiline strings!

At first glance, this seems to be the perfect file format. Consider our example in YAML form:

database:
  host: localhost
  port: 5432
  name: myapp_db
server:
  debug: true
  port: 8080

It is both beautiful and easy to understand and implement. You can easily write a 200-300 line YAML configuration file by hand without breaking a sweat.

There aren’t many cons we can think about. One of them is most likely the main value on how it was built, based on indentation. Indentation is good in theory, but indentation sensitivity is a notorious source of bugs.

The other thing we can think about, but it is not actually the YAML structure fault, is the fact that some parsers will fail or produce some surprises. For example, “no”, “yes”, “on”, and “off” are parsed as booleans in some parsers.

Apart from that, we can't say much negative about it in our professional opinion. That is probably why this is the commonly used file format for DevOps tooling, infrastructure as code solutions, CI/CD pipelines, or other modern technologies.

TOML

TOML is a newer file format that was intended to fill gaps in the INI while remaining simpler than YAML. This has become the favorite choice for those working on Rust projects, Python packaging, or Hugo static sites.

Check out how our configuration would look in TOML:

[database]
host = "localhost"
port = 5432
name = "myapp_db"
[server]
debug = true
port = 8080

Familiar, isn't it? If the file didn't have the .toml extension, you would believe that this is actually an INI file.

The similarity with the INI file types is what made it popular, because the INI format was already popular and widely used, and it just needed some adjustments. Because they share the same structure, you have far fewer parsing inconsistencies than YAML.

However, TOML natively supports dates, arrays, inline tables, and multiline strings, completing everything that was missing in INI files.

Although it is widely used in Rust and Python, it has a smaller community and tooling ecosystem than JSON or YAML. One of the reasons could be its age, but we believe these will increase over time.