XML을 JSON으로

An XML-to-JSON converter walks an XML document tree and emits a JSON value that represents the same hierarchy. Every element becomes an object, every attribute is folded into that object under a convention-driven key (often prefixed with @), text content lives under another conventional key (often #text), and repeated sibling elements collapse into a JSON array. The result is not XML written differently; it is XML reshaped into the only two container types JSON has — objects and arrays.

Why convert in this direction at all

XML still dominates feeds, configuration files, legacy SOAP services, and many enterprise document exchanges. JSON dominates modern HTTP APIs, JavaScript runtimes, and most debugging tools. Converting XML to JSON is the bridging step whenever data that arrived as XML has to be consumed, displayed, or queried by something that only speaks JSON — without rewriting either side of the connection.

How XML constructs map onto JSON, and where they cannot

JSON has objects, arrays, strings, numbers, booleans, and null. XML has elements, attributes, mixed text, namespaces, processing instructions, CDATA, and ordering rules. Most XML constructs do map onto JSON, but the mapping is by convention rather than by specification — every converter picks one. Knowing the convention this tool uses makes it much easier to audit the output and to predict what downstream code will see.

• Each element becomes a JSON object keyed by its tag name; nested elements live as nested objects under that key.
• Attributes fold into the same object under a conventional prefix (commonly @attr) so they do not collide with child element names.
• Text content sits under a conventional key (often #text or _), used only when an element also has attributes or children alongside its text.
• Two or more sibling elements with the same tag name collapse into an array under that key — but a single child element with that name stays as an object. Downstream code has to handle both shapes.
• Namespaces are kept as part of the tag name (prefix:tag) unless the converter is told to strip them — silently dropping a namespace is the fastest way to make two superficially identical documents mean different things.

Rule of thumb: write down which convention you expect (attribute prefix, text key, array policy, namespace handling) before you start auditing. The output is only wrong relative to a convention you have decided on.

이 도구 사용 방법

1. Prepare representative XML documents that need API-friendly or parser-friendly structured output in XML을 JSON으로 instead of starting with the largest or most sensitive real input.
2. Run the workflow, generate JSON text that reflects the XML hierarchy for review, and review attributes, repeated elements, text-node content, namespaces, and whether the source XML mixes data with presentation structure before deciding the result is ready.
3. Only copy or download the result after it fits API migration, support debugging, import prep, and XML cleanup and no longer conflicts with this constraint: XML attributes, namespaces, and repeated nodes can flatten in ways that need manual review after conversion.

XML을 JSON으로 예시

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

예시 입력

<item><name>ToolKit</name><active>true</active></item>

예상 출력

{
  "item": {
    "name": "ToolKit",
    "active": "true"
  }
}

A small XML document and the JSON it produces

<!-- XML -->
<library>
  <book id="1" lang="en">
    <title>XML in a Nutshell</title>
    <author>Eckstein</author>
  </book>
  <book id="2" lang="en">
    <title>Effective Java</title>
    <author>Bloch</author>
  </book>
</library>

// JSON
{
  "library": {
    "book": [
      { "@id": "1", "@lang": "en", "title": "XML in a Nutshell", "author": "Eckstein" },
      { "@id": "2", "@lang": "en", "title": "Effective Java",   "author": "Bloch" }
    ]
  }
}

Notice that the two sibling book elements collapse into an array, while attributes (@id, @lang) live alongside child element keys inside the same object. If there had been only one book element, book would be an object instead of an array.

When converting XML to JSON is the right step

The conversion is most useful at the boundary where XML-producing systems meet JSON-consuming ones. Once the data crosses that boundary, every downstream tool gets cheaper to integrate with.

• Importing an RSS or Atom feed into a JavaScript-based reader or research script that has no XML parser in its stack.
• Quickly inspecting a complex XML response by browsing the converted JSON in DevTools.
• Bridging a legacy SOAP service to a modern HTTP API at the gateway layer.
• Feeding XML configuration into a JSON-only validator, linter, or schema-inference tool.
• Sharing a partner's XML export with non-engineering teammates without making them install a viewer.

Edge cases worth double-checking after the conversion

XML can express things JSON cannot. Most surprising results from this conversion are not bugs — they are the spots where the source XML relied on something the JSON convention had to flatten, rename, or drop.

• Element order: XML preserves it; JSON object keys do not. If order matters, keep children as a JSON array rather than promoting them to object keys.
• Mixed content: an element with both text and child elements has no clean JSON shape; converters usually split it into chunks, which is lossy for document-style XML.
• Namespaces: stripping the prefix may make the JSON look cleaner but silently merges elements XML treated as different. Keep prefixes when in doubt.
• Numeric-looking strings: an XML value like 007 is text. If the converter coerces it to a number, leading zeros disappear and downstream comparisons fail.
• CDATA blocks: contents must stay verbatim. A converter that strips wrapping CDATA markers is fine; one that re-escapes or trims the body is not.

실무 참고

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

XML을 JSON으로 참고 정보

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

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

참고 자료

• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
• ECMA-404: The JSON Data Interchange Syntax
• W3C: Extensible Markup Language (XML) 1.0