📄 XML ⇔ JSON 변환

XML ⇔ JSON 양방향 변환. 속성 접두사, 텍스트 노드 키, CDATA, 배열 자동 감지. RSS / SOAP 같은 복잡한 XML도 처리.

완전 무료 가입 불필요 브라우저 완결 5 개 언어 다크 모드

🔒 개인정보 보호

・모든 처리는 브라우저 내에서 완료됩니다
・입력 데이터는 서버로 전송되지 않습니다

방향

속성 접두사

텍스트 키

들여쓰기

배열 자동

Input

Output

🔗 관련 도구

📖 자주 걸리는 지점

XML 과 JSON 을 상호 변환합니다. 속성의 프리픽스 · 텍스트 노드의 키 이름 · CDATA · 배열의 자동 검출에 대응하며 RSS 나 SOAP 같은 복잡한 XML 도 다룰 수 있습니다. 처리는 브라우저 안에서 끝납니다. 다만 이 둘은 데이터 모델이 다르므로 변환은 본질적으로 비가역입니다 — XML → JSON → XML 로 왕복시켜도 원래 파일로는 돌아오지 않습니다. 단방향의 취득에 쓰는 것이라고 생각하세요.

사례	무슨 일이 일어나는가	어떻게 하면 되는가
왕복시켰더니 XML 이 다른 것이 되었다	JSON 에는 속성이라는 개념도, 요소의 순서를 유지하는 구조도, 주석도 없습니다. 따라서 왕복에서 잃는 것은 다방면에 이릅니다 — 속성의 기술 순서, 네임스페이스의 접두사(`ns1:` 이 `ns2:` 로 바뀌어도 XML 로서는 동등), `<a/>` 와 `<a></a>` 의 구분, 주석, DOCTYPE, 처리 명령, 요소 간의 공백. 특히 중대한 것은 전자 서명입니다 — XMLDSig 는 바이트열 그 자체에 대해 서명하므로 왕복시킨 시점에 검증에 실패합니다. SOAP 나 전자 인보이스를 다루는 장면에서는 치명적입니다.	왕복시키지 않는 설계로 하세요. XML 을 받아 앱 안에서 쓴다면 JSON 으로 변환하고 돌려줘야 할 XML 은 원래 파일을 그대로 보관해 두거나 템플릿에서 다시 생성합니다. 서명이나 검증이 얽히는 장면에서는 애초에 XML 그대로 다룰 수 있는 라이브러리를 쓰는 것이 정답입니다(JSON 으로의 변환은 어디까지나 사람이 내용을 읽기 위한 보조라고 딱 잘라 생각하세요). 변환이 가역인지 확인하고 싶다면 왕복시킨 결과를 원본 파일과 diff 하는 것이 가장 빠릅니다 — 문제가 일어난 뒤에 알아차리기보다 처음에 한 번 시험해 한계를 파악해 두는 편이 안전합니다.
같은 태그가 한 건일 때만 배열이 되지 않는다	배열 자동 검출은 실제 출현 횟수로 판단합니다. 따라서 `<item>` 이 3 건 있으면 배열이 되고 1 건밖에 없으면 오브젝트가 됩니다. 같은 스키마의 XML 인데 데이터의 내용에 따라 JSON 의 형태가 달라진다는 것이며 받는 쪽 코드는 `items.map(...)` 에서 떨어집니다. 이는 XML → JSON 변환에서 가장 빈번하게 밟히는 버그이며 게다가 테스트용 샘플에는 여러 건 들어 있는 경우가 많으므로 프로덕션에서 우연히 1 건이던 날에 처음 깨집니다. RSS 피드나 검색 결과의 취득에서 전형적으로 일어납니다.	스키마를 알고 있다면 그 요소는 항상 배열로 다루세요. 많은 라이브러리에는 `alwaysArray` / `arrayNotation` 같은 옵션이 있어 태그 이름을 열거해 이것은 반드시 배열 이라고 선언할 수 있습니다. 라이브러리 쪽에서 지정할 수 없는 경우에는 받는 쪽에서 `const list = [].concat(data.items?.item ?? [])` 처럼 정규화하는 것이 확실합니다 — 이 한 줄을 쓰는 습관을 들이는 것만으로 이런 종류의 장애는 거의 사라집니다. 테스트 데이터에는 반드시 0 건 · 1 건 · 여러 건 세 패턴을 넣으세요 — 실제로 깨지는 것은 앞의 두 가지이고 그 앞의 두 가지는 샘플에 들어 있지 않은 것이 보통입니다.
네임스페이스가 붙은 키가 JavaScript 에서 다루기 어렵다	`<dc:creator>` 는 JSON 에서는 `"dc:creator"` 라는 키가 됩니다. 콜론을 포함하므로 점 표기로 쓸 수 없고 `obj.dc:creator` 는 구문 오류입니다. RSS 나 Atom 은 네임스페이스를 반드시 쓰므로 피드를 다루면 확실히 부딪힙니다(`content:encoded`, `media:thumbnail`, `itunes:duration` 등). 더 까다로운 것은 접두사는 문서마다 자유롭게 정할 수 있다는 점입니다 — 같은 네임스페이스 URI 라도 어떤 피드는 `dc:`, 다른 피드는 `dcterms:` 를 쓰므로 접두사를 못 박은 코드는 다른 피드에서 동작하지 않습니다.	접근은 브래킷 표기 `obj["dc:creator"]` 로 쓰세요. TypeScript 의 타입 정의에서도 마찬가지로 따옴표가 붙은 키 이름으로 선언할 수 있습니다. 접두사의 흔들림에 대처하려면 취득 시에 정규화하는 것이 유일한 현실적인 방법입니다 — 접두사를 떼고 `creator` 로 하거나 네임스페이스 URI 로 해결한 뒤 직접 정한 짧은 이름으로 바꿔 답니다. 다만 단순히 접두사를 떼면 충돌할 수 있다는 점에 주의하세요(`dc:date` 와 `atom:date` 가 둘 다 `date` 가 됩니다). 실제 피드를 5 개 정도 모아 시험하면 상정하지 않았던 접두사가 금방 발견됩니다 — 사양서를 읽는 것보다 빠른 확인 방법입니다.

숫자로 보이는 문자열에 주의하세요. XML 은 모두 텍스트이므로 <zip>007-0000</zip> 도 <tel>+81...</tel> 도 문자열이지만 변환 구현에 따라서는 숫자 같은 것을 자동으로 숫자로 변환합니다 — 그 순간에 맨 앞의 0 이 사라지고 1e5 는 100000 이 되며 +81 은 81 이 됩니다. 우편번호 · 전화번호 · 제품 코드 · 버전 번호는 반드시 문자열 그대로 다루는 설정으로 하세요. 또 한 가지, 외부에서 받은 XML 을 서버 쪽에서 파스할 때는 XXE(외부 실체 참조)에 주의하세요 — 브라우저의 DOMParser 는 외부 실체를 전개하지 않으므로 이 페이지의 처리는 안전하지만 서버 쪽 파서는 구현에 따라 기본적으로 유효합니다. PHP 라면 LIBXML_NOENT 를 넘기지 않는다, Java 라면 setFeature 로 외부 실체를 무효화한다 같은 대책이 필요합니다. 로컬 파일의 내용이 빠져나간다는 고전적인 취약점이지만 지금도 흔히 발견됩니다.

📖 사용법

1

방향과 옵션 설정

XML → JSON 또는 JSON → XML을 선택하고 속성 접두사, 텍스트 키, 들여쓰기를 지정하세요.
2

데이터 입력

왼쪽에 XML 또는 JSON을 붙여넣으세요. 샘플 버튼으로 RSS나 속성 포함 JSON을 불러올 수 있습니다.
3

결과 복사 또는 다운로드

변환 결과가 오른쪽에 실시간으로 표시됩니다. 복사 또는 다운로드 버튼으로 저장하세요.

❓ 자주 묻는 질문

속성과 텍스트 노드는 어떻게 표현되나요?

속성은 접두사가 붙은 키(예: @id), 텍스트 노드는 지정한 키(예: #text)로 저장됩니다. 옵션으로 변경 가능합니다.

CDATA 섹션을 지원하나요?

네. XML → JSON에서는 CDATA 내용을 텍스트로 보존하고, JSON → XML에서는 예약 문자를 포함한 값을 자동으로 CDATA로 감쌉니다.

같은 태그가 여러 개일 때 배열이 되나요?

"배열 자동" 활성화 시 같은 태그가 둘 이상이면 배열로 묶입니다. 비활성화 시 나중 값이 이전 값을 덮어씁니다.

🐛 이 도구에서 문제가 발생했나요?

무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.