JSON을 TOML로

A JSON-to-TOML converter rewrites a JSON document — an object of nested objects, arrays, and primitive values — into a TOML file that expresses the same data in a layout designed for humans to edit. The data does not change; only its presentation does. Where JSON uses braces, commas, and quoted keys, TOML uses section headers, dotted keys, and a more visually open structure that reads top-to-bottom like a configuration document.

Why convert this direction at all

Most JSON-to-TOML conversions happen at a hand-off boundary. A machine produces JSON (an API response, a generated config snapshot, a default exported from code), but the next person in the chain needs to read, edit, and check that file in by hand. TOML is far more comfortable for that — it supports comments, it groups related keys under section headers, and it does not punish you for adding a trailing line break. Converting once at the boundary saves the editor from squinting at one-line JSON for the rest of the file's life.

How JSON constructs map onto TOML

TOML covers almost everything JSON can express, plus a few things JSON cannot (comments, native dates). Knowing the mapping ahead of time makes the output much easier to audit and to plan around.

• Top-level objects become a flat list of key = value pairs at the start of the TOML file.
• Nested objects become [section] headers; deeper nesting uses dotted headers like [server.tls].
• Arrays of objects with the same shape become arrays of tables, marked with [[double-bracket]] headers — one block per array element.
• Arrays of primitives stay inline as JSON-like literals: tags = ["alpha", "beta"].
• Booleans, integers, floats, and strings keep their types. Strings with quotes or newlines may use triple-quoted or literal-string form.
• JSON null has no direct TOML equivalent. The converter has to either drop the key, emit a placeholder string, or refuse — its choice should be explicit, not silent.

Rule of thumb: a converted TOML file should round-trip back to the same JSON structurally. If a key disappears, an array changes shape, or a number turns into a string, the conversion needs a second look.

이 도구 사용 방법

1. Prepare representative JSON configuration data that needs TOML output for tooling or app configs in JSON을 TOML로 instead of starting with the largest or most sensitive real input.
2. Run the workflow, generate copyable TOML text for configuration review, and review table sections, arrays, booleans, quoting, nested objects, and whether the target config format expects flat or grouped keys before deciding the result is ready.
3. Only copy or download the result after it fits application config drafting, tooling setup, and format migration and no longer conflicts with this constraint: TOML has stricter configuration semantics than generic JSON, so review nested tables and value types before deployment.

JSON을 TOML로 예시

JSON을 TOML로 예시는 작고 대표적인 JSON 샘플로 시작하는 것이 좋습니다. 생성된 TOML 구조를 먼저 확인한 뒤 같은 변환을 실제 큰 데이터에 적용할 수 있습니다.

예시 입력

{"title":"ToolKit Online","draft":false}

예상 출력

title = "ToolKit Online"
draft = false

A small JSON document and its TOML equivalent

// JSON
{
  "title": "Sample",
  "enabled": true,
  "server": { "host": "localhost", "port": 8080 },
  "database": { "primary": { "url": "postgres://localhost/app", "pool": 20 } },
  "entries": [
    { "name": "alpha", "weight": 1.5 },
    { "name": "beta",  "weight": 2.0 }
  ]
}

# TOML
title = "Sample"
enabled = true

[server]
host = "localhost"
port = 8080

[database.primary]
url = "postgres://localhost/app"
pool = 20

[[entries]]
name = "alpha"
weight = 1.5

[[entries]]
name = "beta"
weight = 2.0

Notice how nested objects become section headers and the array of objects becomes [[entries]] blocks. That is what makes the TOML version easy to extend by hand.

When converting JSON to TOML is the right move

Convert in this direction whenever ownership of the file is about to shift from a process to a person — once a human will edit it next, TOML pays back the conversion many times over.

• Seeding a project's first config file from an API response or a code-generated default.
• Migrating a JSON config (often package.json-style settings) to a separate file that lives more comfortably in source control with comments.
• Producing a starter config for tools that prefer TOML (Cargo, pyproject, Hugo, many Go binaries) from data already encoded as JSON.
• Sharing a configuration snapshot with a teammate for review — a TOML version is much easier to skim than a long-line JSON dump.
• Building documentation that includes the canonical configuration — TOML embeds in prose more cleanly than JSON.

Edge cases that need attention when going from JSON to TOML

TOML is strict about a few things that JSON is loose about. Most failed conversions surface at those exact spots — knowing them up front lets you adjust the source JSON instead of fighting the converter.

• null values: TOML has no null. Decide whether each null should be dropped, replaced with a sentinel string, or treated as an error.
• Mixed-type arrays: TOML allows arrays of homogeneous types only. [1, "two", true] is illegal — split it into separate keys or restructure.
• Keys that contain dots, spaces, or special characters: TOML requires them to be quoted, which can look noisy. Renaming the source key is usually cleaner.
• Deeply nested arrays of arrays: representable in TOML but visually noisy. Consider flattening to dotted keys when the depth exceeds three.
• Numbers that JSON treated as plain floats but TOML may interpret as integers when the trailing .0 is lost. Keep the source explicit if precision matters.
• Object key ordering: JSON does not guarantee order; TOML readers care about the order of [section] declarations relative to top-level keys. Decide on a stable ordering policy in the source.

JSON and TOML on the things people actually care about

실무 참고

• JSON을 TOML로는 대표적인 JSON 샘플로 먼저 시험해 필드 이름, 중첩 구조, 빈 값, 특수 문자가 TOML 변환 후에도 유지되는지 확인한 뒤 사용하는 것이 좋습니다.
• 생성된 TOML 결과는 최종 대상 시스템에서도 다시 검토해야 합니다. 파서, 가져오기 도구, 스키마 기대치에 따라 경계 사례 처리 방식이 다를 수 있기 때문입니다.
• 이 변환이 운영 데이터에 영향을 줄 수 있다면 브라우저 출력은 초안으로 보고, 원본 입력을 함께 보관해 비교할 수 있게 하세요.

JSON을 TOML로 참고 정보

JSON을 TOML로의 참고 설명은 JSON 구조가 TOML 출력으로 어떻게 바뀌는지와, 재사용 전에 무엇을 검토해야 하는지에 초점을 맞춥니다.

• TOML 결과를 믿기 전에, 입력한 JSON 샘플 자체의 구조가 올바른지 먼저 확인하세요.
• 변환 후에는 중첩 배열, 혼합 값 유형, 빈 필드, 특수 문자를 우선적으로 살펴보세요.
• 생성된 TOML 출력은 후속 편집기, 파서, 가져오기 도구, 런타임에서 기대를 충족하기 전까지 초안으로 다루세요.

참고 자료

• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
• ECMA-404: The JSON Data Interchange Syntax
• TOML v1.0.0