Which Configuration File Format Should You Use? (A Developer’s Perspective)

When I first started building apps, I did what many beginners do: I hard-coded everything. Database URL, API key, and Debug mode? Yep, hard-coded.

It worked… until I needed to deploy to production. Suddenly my “localhost:5432” didn’t make sense anymore, and I realized: I needed a way to separate settings from code. That’s when I entered the jungle of configuration files.

But here’s the good news: over the years I’ve tried them all — .ini, .json, .yaml, .toml, .xml, and of course .env files — and each has its place. Let’s walk through them in plain English so you can decide what’s best for your project.

INI — The Old Reliable

If you’ve touched Windows apps or PHP, you’ve seen this one (php.ini anyone?). It looks like this:

[database]
host=localhost
port=5432

Why it’s good: simple, human-friendly, works out of the box in Python with [configparser](https://docs.python.org/3/library/configparser.html). Where it struggles: doesn’t handle nested/complex data well.

I still see it in Python tools (pytest.ini, tox.ini) and it’s great for small apps or personal projects.

JSON — The Everywhere Format

You know this one. It powers almost every API response and is supported in literally every language.

{
  "database": {
    "host": "localhost",
    "port": 5432
  }
}

Why it’s good: strict, universal, tooling everywhere. Pain point: configs can feel sterile.

If you’re building something that needs to talk across languages or platforms, JSON is a safe bet.

YAML — The DevOps Darling

If you’ve ever written a Docker Compose file, Kubernetes manifest or an Ansible playbook, you’ve fought with YAML.

database:
  host: localhost
  port: 5432

Why it’s good: easy to read, supports comments, handles deep nesting. Where it hurts: indentation errors.

Still, YAML is unbeatable in cloud-native and infrastructure-as-code setups.

TOML — The Modern Minimalist

TOML is like INI, but with more clarity and types.

[database]
host = "localhost"
port = 5432

Why it’s good: clean, typed, perfect balance between readability and strictness. Catch: not as widespread as JSON or YAML.

In Python, you already use it: pyproject.toml is now standard for packaging.

XML — The Enterprise Veteran

XML used to rule the world of configs (and still does in enterprise).

<database>
  <host>localhost</host>
  <port>5432</port>
</database>

Why it’s good: mature, schema validation, tons of tooling. Downside: verbose and painful to hand-edit.

If you’re working in Java/.NET enterprise systems, XML will probably still cross your path.

.ENV — The Secret Keeper

This one’s simple and pairs perfectly with the Twelve-Factor App philosophy.

DATABASE_HOST=localhost
DATABASE_PORT=5432

Why it’s good: great for secrets, plays nicely with Docker/Kubernetes, works with python-dotenv. Not ideal for: complex nested data.

Almost every modern Python web app I’ve seen uses .env files for local dev and CI/CD pipelines.

So… Which One Should You Use?

Here’s my honest take after years of juggling them:

• Small apps / legacy tools → INI
• APIs / cross-language → JSON
• DevOps / cloud-native → YAML
• Modern Python projects → TOML
• Enterprise / schema-heavy → XML
• Secrets & environments → .ENV

In reality, most teams mix and match:

• Use .env for secrets,
• YAML or JSON for structured configs,
• TOML for project tooling.

Final Thoughts

There isn’t one “best” configuration file. The “best” is the one that fits your project’s context.

The important thing is:

• Don’t hardcode your configs.
• Keep them versioned.
• Match the tool to the problem.

And if you’re building something bigger — with multiple environments, teams, and secrets — check out tools like **Configu, HashiCorp Vault, or Dynaconf** to tame the chaos.