XML 포맷터·검증기

XML·SVG·RSS를 예쁘게 정렬하거나 압축하고, 문법 오류를 줄:칸 위치로 짚어 줍니다. 트리뷰 지원.

XML 입력

📁 .xml / .svg / .rss 파일을 끌어다 놓거나 클릭해서 선택

파일은 브라우저에서만 읽습니다 · 최대 8MB

결과

들여쓰기 빈 요소를 <a/> 로 축약 주석 유지

검증은 브라우저 내장 XML 파서(DOMParser)가 합니다. 오류가 나면 파서가 알려 주는 줄:칸 위치를 그대로 표시하고 원인을 한국어로 풀어 씁니다. XML 파서는 문제가 시작된 곳이 아니라 문제를 알아챈 곳을 가리키기도 하니, 표시된 줄부터 위로 훑어보세요.
보존 — CDATA, 주석, 처리명령(<?xml?> 등), DOCTYPE, 네임스페이스 접두사, 속성 순서를 그대로 유지합니다. 텍스트와 자식 요소가 섞인 요소(mixed content)는 공백이 데이터일 수 있어 줄바꿈 없이 한 줄로 둡니다.
외부 엔티티 — 처리하지 않습니다. DOMParser는 외부 DTD·엔티티를 가져오지 않으므로 XXE 같은 위험이 없고, 파일 안에 SYSTEM 엔티티 선언이 있어도 네트워크 요청이 발생하지 않습니다. 정의되지 않은 엔티티는 오류로 표시됩니다.

XML 포맷터·검증기란?

XML은 아직도 공공데이터 오픈API 응답, RSS 피드, SVG 이미지, 각종 설정 파일에서 현역으로 쓰입니다. 그런데 서버가 내려 주는 XML은 대개 줄바꿈 없이 한 줄로 뭉쳐 있어서 어떤 요소가 어디에 중첩돼 있는지 읽기가 어렵습니다. 이 도구는 XML을 붙여넣으면 계층에 맞춰 들여쓰기해 주고, 반대로 전송 크기를 줄이기 위한 압축도 해 줍니다. 검증은 브라우저에 내장된 DOMParser가 담당합니다. 태그가 안 닫혔거나 여는 태그와 닫는 태그 이름이 다르거나 & 를 그냥 썼을 때 브라우저가 뱉는 영어 오류를 사람이 읽을 수 있는 한국어 메시지로 바꾸고 몇 번째 줄 몇 칸인지 짚어 줍니다. CDATA 블록, 주석, XML 선언 같은 처리명령, 네임스페이스 접두사는 원문 그대로 보존하며, 트리뷰로 전환하면 구조를 접었다 펼치며 살펴볼 수 있습니다.

사용 방법

입력창에 XML을 붙여넣거나 .xml/.svg/.rss 파일을 끌어다 놓습니다.
입력하는 즉시 문법 검증이 돌아가며, 오류가 있으면 줄:칸 위치와 원인을 알려 줍니다.
"정렬"을 누르면 들여쓰기된 XML이, "압축"을 누르면 공백을 걷어낸 XML이 만들어집니다.
트리 보기로 전환해 요소 구조를 접었다 펼치며 확인합니다.
요소 수·최대 깊이·속성 수 통계를 확인하고, 결과를 복사하거나 파일로 저장합니다.

XML 포맷터·검증기 사용 가이드

실제 작업에서 이 도구를 어떻게 쓰는지, 무엇을 조심해야 하는지 정리했습니다.

XML을 아직도 만나는 자리 — 특히 한국에서

"요즘은 다 JSON 아닌가요"라고 생각하다가 XML을 만나는 곳이 있습니다. 한국에서는 특히 공공 데이터입니다. 공공데이터포털(data.go.kr)의 오픈API 상당수가 XML 응답을 기본으로 하고, JSON은 dataType 같은 파라미터를 따로 넣어야 나오거나 아예 제공하지 않는 경우도 있습니다. 기상청 단기예보, 국세청 사업자등록 상태 조회, 도로명주소 API를 붙여 본 적이 있다면 익숙할 것입니다.

공공데이터 오픈API 응답 — 한 줄로 뭉쳐 오는 경우가 많아, 붙여넣고 정렬하면 resultCode·resultMsg 가 어디 있는지 바로 보입니다.
RSS·아톰 피드 — 블로그·뉴스 피드는 여전히 XML입니다. 피드 리더가 안 읽을 때 문법부터 확인하세요.
SVG — 벡터 이미지는 그냥 XML입니다. 정렬해서 열면 어떤 path 가 어느 그룹에 들어 있는지 눈으로 따라갈 수 있습니다.
사이트맵(sitemap.xml) — 검색엔진에 제출하기 전 문법 검사용으로 씁니다.
전자세금계산서·EDI·각종 정부 표준 서식 — 스키마가 XML로 정의된 영역이 아직 넓습니다.

파일은 드래그해서 놓을 수 있고 .svg·.rss 확장자도 받습니다. 브라우저가 직접 읽으므로 업로드가 일어나지 않습니다.

오류가 났을 때 — 흔한 원인 5가지

검증은 브라우저 내장 XML 파서(DOMParser)가 합니다. 파서가 알려 주는 줄:칸을 그대로 보여 주고 원인을 한국어로 풀어 씁니다. 실제로 걸리는 원인은 거의 아래 다섯입니다.

& 를 그냥 씀 — XML에서 & 는 엔티티의 시작입니다. URL 쿼리스트링(?a=1&b=2)을 값에 넣으면 그 자리에서 터집니다. & 로 쓰거나 CDATA로 감싸세요.
태그 이름 대소문자 불일치 — <Title>공지</title> 는 오류입니다. HTML과 달리 XML은 대소문자를 구분합니다.
닫지 않은 빈 태그 — 이나 <img src="…"> 같은 HTML 습관이 그대로 들어오면 오류입니다. 처럼 닫아야 합니다.
HTML 전용 엔티티 —   나 © 는 XML에 정의돼 있지 않습니다.   · © 처럼 숫자 문자 참조로 바꾸세요.
루트 요소가 둘 — 응답 두 개를 이어붙이면 이 오류가 납니다. XML 문서에는 최상위 요소가 하나뿐이어야 합니다.

XML 파서는 문제가 시작된 곳이 아니라 문제를 알아챈 곳을 가리킵니다. 위쪽에서 태그를 안 닫으면 한참 아래 줄을 지목하기도 합니다. 표시된 줄부터 위로 거슬러 올라가며 짝이 안 맞는 태그를 찾으세요. 트리 보기로 바꾸면 어디서 중첩이 어긋났는지 더 빨리 보입니다.

네임스페이스 — 접두사는 이름이 아니라 별칭

XML 네임스페이스는 서로 다른 출처의 태그가 한 문서에 섞여도 이름이 충돌하지 않게 하는 장치입니다. RSS 피드에 <dc:creator>·<content:encoded> 가 섞이고, 정부 표준 서식에 여러 스키마가 겹치는 것이 그 예입니다.

헷갈리기 쉬운 점 — 태그의 정체를 정하는 것은 접두사(dc:)가 아니라 그 접두사가 가리키는 URI입니다. 접두사는 그냥 별칭이라, 루트의 xmlns:dc="…" 선언만 바꾸면 같은 dc:creator 가 다른 뜻이 됩니다. 그래서 이 도구는 접두사와 선언을 원문 그대로 보존합니다. 임의로 정규화하면 문서의 의미가 달라질 수 있기 때문입니다.

xmlns 선언은 속성처럼 생겼지만 지우면 안 됩니다. 지우는 순간 "선언되지 않은 접두사" 오류가 납니다.
기본 네임스페이스(접두사 없는 xmlns)는 그 요소와 자손 전체에 적용됩니다. 일부만 복사해 붙이면 선언이 딸려오지 않아 뜻이 달라집니다.
속성 순서도 그대로 둡니다. XML 표준상 속성 순서에는 의미가 없지만, 원문과 diff 를 뜨는 사람에게는 의미가 있기 때문입니다.

CDATA — 언제 쓰고 무엇을 조심하나

CDATA는 "이 안은 마크업으로 해석하지 말고 글자 그대로 읽어라"라는 구역입니다. RSS의 description 안에 HTML 본문을 넣을 때가 대표적입니다. 안 그러면 본문의 모든 < 와 & 를 이스케이프해야 하는데, 읽지도 못할 문자열이 됩니다.

CDATA 안에는 ]]> 라는 문자열을 넣을 수 없습니다. 종료 표시이기 때문입니다. 본문에 그 조합이 나오면 CDATA를 두 개로 쪼개는 우회법을 씁니다.
CDATA는 파싱을 막는 것일 뿐 보안 장치가 아닙니다. CDATA로 감싼 HTML을 그대로 화면에 꽂으면 XSS가 그대로 통과합니다.
이 도구는 CDATA·주석·처리명령·DOCTYPE 을 원문 그대로 보존합니다. "주석 유지"를 끄면 압축 시 주석만 제거됩니다.

xml

<!-- 이스케이프 방식: 읽기 어렵다 -->
<description>&lt;p&gt;오늘 &amp; 내일&lt;/p&gt;</description>

<!-- CDATA 방식: 원문 그대로 -->
<description><![CDATA[<p>오늘 & 내일</p>]]></description>

정렬해도 원문이 안 깨지나 · 외부 엔티티

요소 사이의 의미 없는 공백만 정리하고, 텍스트와 자식 요소가 섞인 요소(mixed content)는 줄바꿈 없이 한 줄로 둡니다. 안녕 홍길동님 에서 "안녕 " 뒤의 공백은 데이터라, 예쁘게 들여쓰면 렌더링 결과가 달라지기 때문입니다.

"빈 요소를 축약" 옵션은 여는 태그와 닫는 태그가 붙어 있는 빈 요소를 self-closing 형태로 바꿉니다. XML 표준에서 둘은 완전히 동일하지만, 받는 쪽이 문자열 비교로 검사하는 낡은 시스템이라면 꺼 두는 편이 안전합니다.

외부 엔티티(XXE)는 처리하지 않습니다. 브라우저 DOMParser 는 외부 DTD·엔티티를 가져오지 않으므로, 문서 안에 SYSTEM 엔티티 선언이 있어도 네트워크 요청이 발생하지 않습니다. 다만 이건 이 도구가 안전하다는 뜻이지, 같은 파일을 서버의 XML 파서에 넣어도 안전하다는 뜻은 아닙니다. 서버 쪽 파서는 별도로 외부 엔티티를 꺼야 합니다.

자주 묻는 질문

오류 위치는 정확한가요?

브라우저 DOMParser가 알려 주는 줄·칸 정보를 그대로 씁니다. XML 파서는 문제가 실제로 시작된 곳이 아니라 문제를 깨달은 지점을 가리키는 경우가 있어서, 예를 들어 위쪽에서 태그를 안 닫으면 한참 아래쪽 줄을 지목하기도 합니다. 이럴 땐 표시된 줄부터 위로 거슬러 올라가며 짝이 맞지 않는 태그를 찾으세요.

외부 엔티티(XXE)는 어떻게 처리되나요?

처리하지 않습니다. 브라우저 DOMParser는 외부 DTD나 외부 엔티티를 가져오지 않으므로 XXE 같은 공격 표면 자체가 없습니다. 문서 안에 SYSTEM 엔티티 선언이 있어도 네트워크 요청이 발생하지 않으며, 정의되지 않은 엔티티는 오류로 표시됩니다.

정렬하면 원문이 달라지나요?

요소 사이의 의미 없는 공백은 정리되지만 CDATA·주석·처리명령·속성 순서·네임스페이스 접두사는 보존됩니다. 다만 XML에서 공백이 데이터인 경우가 있어서, 요소 안에 텍스트와 자식 요소가 섞여 있으면(mixed content) 줄바꿈을 넣지 않고 한 줄로 둡니다.

HTML도 넣을 수 있나요?

XML 파서로 검사하므로 XML 규칙을 지킨 문서만 통과합니다. 닫지 않는 태그나   같은 HTML 전용 엔티티가 있으면 오류가 납니다. XHTML 형태로 처럼 닫고 엔티티를 숫자 문자 참조로 바꾸면 처리됩니다.

입력한 XML이 서버로 전송되나요?

아니요. 파싱·정렬·검증 전부 브라우저 안에서만 실행되며 내용이 서버로 전송되거나 저장되지 않습니다.