К основному содержимому
DevTools / Конвертер конфигураций

Конвертер конфигураций

Every stack picks a different configuration format, and moving a service from one to another means translating a file by hand unless you have a converter. This tool reads and writes JSON, YAML, TOML, XML, CSV and INI, converts between any pair, and shows both sides at once so you can check that types survived — because the interesting failures in this kind of migration are not syntax errors but a port number that silently became a string.

Работает полностью в браузере — ничего не загружается.

Ввод (JSON)
Вывод (YAML)

Как это работает

The formats divide into two families. JSON, YAML and TOML are data formats with real types: numbers are numbers, booleans are booleans, and null is distinct from the empty string. XML and INI are markup formats with no type system at all — every value is text — so converting into them loses type information and converting back requires inference. This tool infers types when converting out of XML, CSV and INI, treating a bare true, false or null as the corresponding value and a numeric string as a number, and marks inferred values so you can see where the guess happened.

YAML and TOML are the two formats developers most often need to move between. YAML is indentation-sensitive, supports anchors and aliases for reuse, and multiplies into several incompatible dialects depending on which version of the specification and which parser you use. TOML is explicit and unambiguous — every value is assigned with a key, tables are declared with a header — and it has no significant whitespace, which makes it harder to break with a bad paste. TOML has native date and time types that JSON lacks; converting those to JSON produces ISO 8601 strings and converting back is a lossy operation worth checking.

XML is structurally different from all the others because it is a tree with attributes, mixed content and repeated sibling elements. Converting XML to JSON requires choices: an attribute might become a key with a sigil such as @id or a nested object, and a repeated element might become an array or stay a single object until a second one appears. This tool applies a consistent mapping — attributes prefixed with @, text content under #text, repeated elements as arrays — and shows the result so you can see the shape rather than discovering it in production.

CSV is the loosest of the set. There is no standard for nested data, so a nested object has to be flattened into dotted column names such as user.address.city, which is exactly what most analytics and spreadsheet imports expect. The reverse conversion re-inflates those dotted paths into nested objects. Delimiter, quoting and header handling are all configurable, because a semicolon-delimited file exported from a European Excel installation is still CSV and will produce a single-column mess under a comma parser.

Типичные сценарии

  • Translate a JSON fixture into YAML so it can be pasted into a Kubernetes or CI configuration.
  • Convert a TOML application config into JSON to diff it against another environment.
  • Flatten a nested API response into CSV columns for import into a spreadsheet or warehouse.
  • Turn an INI or properties file from a legacy service into structured YAML.
  • Check what a YAML block actually means by converting it to JSON, where the structure is explicit.
  • Move an XML feed into JSON for a service that has no XML parser.

Обновлено: 2026-10-14 — текст статьи показан на английском; интерфейс переведён.

Частые вопросы

Which conversion directions lose information?

Anything converted into XML, CSV or INI loses types, because those formats store only text — a number becomes a string and null becomes an empty value. TOML to JSON loses native date and time types, which become ISO 8601 strings. YAML to JSON loses anchors, aliases and comments, since the conversion is performed on the parsed data and comments are not part of it. JSON to YAML is the only direction that is essentially lossless.

Why did my port number become a string?

Because the source format had no type information. In XML, CSV and INI, everything is text; a value of 8080 is four characters, not a number. This tool infers numeric values on the way out, but inference is a heuristic — a postal code of 01234 or a version string of 1.10 should stay text, and any heuristic that turns them into numbers is worse than none. Check the output for values with leading zeros or multiple dots before trusting them.

How are comments handled?

Comments belong to the file format, not to the data, so they are dropped when parsing and cannot be carried across a conversion. Going from YAML to JSON and back will return a document without its comments. If a comment carries information you need, such as why a value was chosen or which ticket introduced it, keep the original file under version control rather than relying on a round trip.

How is CSV nested data handled?

By flattening. A nested object is turned into dotted column headers, so user.address.city becomes a single column, and arrays are either joined with a separator or expanded into indexed columns such as tags.0 and tags.1. This matches what analytics tools and spreadsheet imports expect. Converting back re-inflates the dotted paths into nested structure, which round-trips cleanly as long as no key legitimately contains a dot.

Связанные инструменты