TOML을 JSON으로

TOML is designed to be edited by people: section headers, comments, multi-line strings, dotted keys. JSON is designed to be consumed by machines: arrays and objects only, no comments, strictly quoted keys. Converting TOML to JSON is the moment a human-friendly configuration file leaves the human side of the workflow and starts feeding tools that only speak JSON — validators, APIs, debugging consoles, schema generators, or whatever language runtime is going to act on it.

What changes in form, what stays in meaning

After conversion the file looks very different — comments, blank lines, section headers, and dotted keys are all gone. What must survive is the structure: every table becomes an object, every value keeps its type, and every key is reachable by the same logical path the TOML author intended.

How TOML constructs map onto JSON

TOML and JSON share most basic types but spell them differently. Knowing the mapping makes it much easier to predict the output shape before running the converter and to spot something off afterwards.

• Tables ([server], [database.primary]) become nested JSON objects, with each dot in the path adding a level of nesting.
• Array of tables ([[entries]]) becomes a JSON array of objects under the same key.
• Inline tables and arrays follow the closest JSON-style syntax and convert almost one-to-one.
• Integers, floats, booleans, and strings keep their types; multi-line and literal strings flatten into ordinary JSON strings with the same value.
• TOML dates and times become strings in JSON, because JSON has no native date type — and that is fine as long as consumers know to parse them.
• Comments and blank lines have no JSON equivalent and are dropped — they are part of the source file, not part of the data.

Rule of thumb: ask yourself which TOML construct you used to express each piece of intent, then check that the corresponding JSON shape carries that intent without ambiguity.

이 도구 사용 방법

1. Prepare representative TOML config files that need JSON for APIs, parsers, or review tools in TOML을 JSON으로 instead of starting with the largest or most sensitive real input.
2. Run the workflow, generate JSON text that mirrors TOML tables and values, and review tables, arrays, booleans, strings, nested sections, and whether comments or formatting carried meaning in the original file before deciding the result is ready.
3. Only copy or download the result after it fits config migration, parser input, API payload prep, and tooling review and no longer conflicts with this constraint: TOML comments and formatting intent do not survive conversion, so focus your review on data structure rather than file layout.

TOML을 JSON으로 예시

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

예시 입력

title = "ToolKit Online"
draft = false

예상 출력

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

A small TOML file with its JSON equivalent

# 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

# 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 }
  ]
}

When TOML → JSON is the right step

TOML stays the source of truth for humans, but JSON is what most automation expects. Conversion is the bridge whenever the two audiences need to share the same data.

• Feeding configuration into an HTTP API or schema validator that only accepts JSON.
• Inspecting a complex TOML file by exploring the converted JSON in a browser DevTools tree, which is often faster than scrolling the original.
• Generating an initial JSON Schema (draft-07) from an existing TOML configuration to lock down expected shape.
• Embedding configuration into a frontend bundle when the runtime cannot pull in a TOML parser.
• Sharing snapshots of a configuration with someone whose tooling only understands JSON (linters, online formatters, scripting languages without a TOML library).

Edge cases worth checking after a TOML → JSON pass

TOML and JSON agree on most things but disagree on a handful that matters in production. Checking these before trusting the converted output saves a lot of debugging later.

• Comments and blank lines are gone. If the config relied on a comment as documentation, move it into a separate README or a description key before converting.
• Dates/times become strings. Consumers must parse them explicitly; do not assume Date.parse will behave the same way across runtimes.
• Numbers: TOML allows large integers and explicit hex/oct/bin notation. JSON only has one number type — confirm precision is still safe after the round trip.
• Dotted keys with the same prefix can collide if also defined as inline tables — the converter should error, not silently merge.
• Array of tables vs inline table arrays look similar but mean subtly different things — verify the JSON shape matches what the consumer expects.

TOML and JSON, compared on what each does best

실무 참고

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

TOML을 JSON으로 참고 정보

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

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

참고 자료

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