TOML, YAML или JSON: какой формат выбрать для конфига нового проекта

Сравнение трех самых популярных форматов конфигурации по читаемости, строгости и экосистемной поддержке, без религиозных войн.

Новый проект, чистый лист, и первый вопрос до единой строчки кода — в каком формате хранить конфиг. Ответ “смотря что вам важнее” звучит как отговорка, но это буквально правда: у каждого из трех форматов есть конкретный набор компромиссов, а не абстрактное “лучше” или “хуже”.

Сравнение по ключевым критериям

Критерий	JSON	YAML	TOML
Комментарии в файле	Нет	Да	Да
Строгость к дублирующимся ключам	Не определена спецификацией	Молча берет последний	Ошибка при парсинге
Читаемость руками без инструментов	Средняя из-за скобок и запятых	Высокая	Высокая
Чувствительность к пробелам	Нет	Критичная	Нет
Нативная поддержка дат	Нет	Да	Да
Экосистема, где формат стандарт де-факто	REST API, конфиги фронтенда	Kubernetes, Docker Compose, Ansible	Cargo.toml, pyproject.toml

Почему JSON редко выбирают для конфигов руками

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

Технически рабочий вариант, но отсутствие комментариев — серьезное ограничение для конфига, который правят люди, а не только машины. Плюс забытая запятая после последнего элемента массива ломает весь файл без внятного объяснения, где именно ошибка. JSON отлично подходит там, где конфиг генерируется и читается программой, но не человеком напрямую.

Опасность YAML: молчаливое затирание дублей

database:
  host: localhost
database:
  host: production-db

Большинство YAML-парсеров молча возьмут второе значение database, без единого предупреждения о том, что ключ был определен дважды. В большом файле с несколькими сотнями строк такую опечатку легко не заметить месяцами, пока не сработает не в том окружении.

TOML как компромисс со строгими правилами

[database]
host = "localhost"
port = 5432

TOML унаследовал читаемость YAML, но добавил строгость JSON: дублирующийся ключ в одной таблице — это явная ошибка парсинга, а не молчаливая перезапись. Плата за это — TOML менее компактен для глубоко вложенных структур, чем YAML, и не так широко поддерживается за пределами экосистем Rust и Python.

Практическая рекомендация без фанатизма

Если конфиг живет в мире Kubernetes, Docker Compose или Ansible — используйте YAML, потому что вся экосистема вокруг уже на нем, и плыть против течения не имеет смысла. Если это независимый проект на Rust или Python без внешних требований к формату — TOML даст больше защиты от тихих ошибок. Если конфиг генерируется и потребляется исключительно программно, без участия человека в правке, — простой JSON часто оказывается более чем достаточным.

Если конфиг уже написан в одном формате, а обстоятельства требуют другого, TOML to YAML Converter и YAML to JSON Converter избавляют от ручного переписывания структуры с нуля.

Итоговый чеклист

JSON — для машинной генерации и потребления, где комментарии и читаемость человеком не приоритет.

YAML — там, где экосистема уже выбрала его за вас, но с осознанием риска молчаливого дублирования ключей.

TOML — разумный выбор для новых независимых проектов, где важна и читаемость, и строгая защита от тихих ошибок конфигурации.