손상된 HTML을 여기에 붙여넣고 "HTML 수정!!"을 클릭해 복구하세요잘못된 HTML 입력

HTML 수정 도구란?

거의 맞는데 페이지가 깨지는 HTML이 있나요? 닫히지 않은 <p>, 떠도는 </div>, 따옴표가 빠진 href 하나만으로도 문서 나머지가 이상한 파싱 상태로 빠질 수 있습니다. 브라우저는 잘못된 마크업으로도 최선을 다하지만 결과가 의도한 대로 나오는 경우는 거의 없죠. 여기에 붙여넣으면 WHATWG HTML 리빙 스탠다드의 규칙에 따라 파서가 만족할 만한 결과를 돌려드립니다.

일상에서 흔히 마주치는 깨짐을 노립니다 — 닫는 태그 누락, 이스케이프되지 않은 따옴표, "가 빠진 속성 값, 닫히지 않은 리스트 항목, 들어가면 안 될 자리에 들어간 중첩 블록 요소. 공식 W3C 검증 도구가 한 번에 한 오류씩 잡아내는 그런 종류죠. 이 수정 도구는 문서 전체를 한 번에 읽고 프로젝트에 그대로 다시 넣을 수 있는 깔끔한 버전을 돌려줍니다.

마크업은 HTTPS로 수정 서비스에 전송되며 보관되지 않습니다. <code>&lt;script&gt;</code>나 <code>data-*</code> 속성에 API 키 같은 인라인 시크릿이 하드코딩돼 있다면 붙여넣기 전에 가려두세요.

HTML 수정 도구 사용 방법

세 단계입니다. 부분 조각, 전체 문서, CMS 내보내기에서 받은 어떤 이상한 조합이든 동작합니다.

1

손상된 HTML 붙여넣기 또는 예시 불러오기

왼쪽 편집기에 HTML을 넣으세요. HTML 예시를 누르면 흔한 실수가 들어 있는 작은 주문 확인 페이지가 로드됩니다 — 닫히지 않은 <head>, </li>가 없는 리스트 항목, 따옴표 없는 href. 손상된 HTML 예시:

<p>Your order <strong>SKU-101 ships tomorrow.
<ul>
  <li>1 x Laptop Stand
  <li>2 x USB-C Cable</li>
</ul>

여기에는 세 가지 실수가 있습니다: <strong>가 닫히지 않고, 첫 번째 <li>가 종료되지 않으며, </p>가 없습니다. 수정 도구가 올바른 순서로 닫아줍니다.

2

HTML 수정!! 클릭

초록색 HTML 수정!! 버튼을 누르세요. 마크업을 수정 서비스로 보내 HTML 구문 규칙에 따라 열린 요소를 닫고, 속성 따옴표를 복원하고, 명백히 잘못된 중첩을 바로잡습니다. 텍스트 콘텐츠, 클래스, id, 인라인 스타일은 그대로 유지됩니다.

3

수정된 결과 확인

오른쪽 패널에 복구된 HTML이 있습니다. 브라우저에 넣어보거나, 검증 차원에서 HTML 검증 도구에 돌리거나, CMS에 다시 붙여넣으세요. 더 깊은 접근성 검토가 필요하면 전용 a11y 도구를 쓰세요 — 그건 구문 수정과는 별개입니다.

실제로 쓰게 되는 순간

CMS 또는 이메일 템플릿 출력 수정

WYSIWYG 편집기와 이메일 템플릿 빌더는 미묘하게 깨진 마크업을 자주 내놓습니다 — 떠도는 <p> 태그, 누락된 alt 속성, 가끔 닫히지 않은 <td>. 게시 전에 한 번만 통과시켜 두면 렌더링된 페이지가 브라우저별로 예상치 못하게 어긋나는 일을 피할 수 있습니다.

Office 앱에서 붙여넣은 마크업 살리기

Word와 Google 문서는 보통 <span>과 독자 속성이 엉킨 채로 붙여 넣어지고, 태그 균형이 안 맞거나 떠도는 &nbsp;가 끼어 있습니다. 수정 도구가 구조를 정리해 주니까 처음부터 다시 쓰지 않고 결과물에서 바로 편집을 이어갈 수 있습니다.

직접 작성한 컴포넌트 복구

튜토리얼, 위키 페이지, 오래된 README의 손으로 친 HTML 조각 — 복사해 넣고, 정리해서, 필요한 곳에 붙여넣습니다. 누군가의 블로그에서는 잘 동작했던 예제가 내 환경에서는 안 될 때 막힘을 푸는 데 유용합니다.

파싱 전 스크랩한 페이지 정돈

HTML을 스크랩해서 추출기에 넣을 때 깨진 마크업은 DOM 기반 파서를 흔들어 놓습니다. 먼저 여기를 통과시켜 파서가 다룰 안정적인 구조를 만들어 주세요. 엄격한 적합성이 필요하면 진짜 검증 도구와 함께 쓰면 됩니다.

자주 묻는 질문

제 HTML이 저장되거나 공유되나요?

붙여넣은 HTML은 수정 처리를 위해 HTTPS로 백엔드에 전송되며, 응답을 돌려드린 뒤에는 보관하지 않습니다. 요청 경로에 서드파티 트래커도 없습니다. 그래도 페이지에 하드코딩된 API 키, 내부 URL, 분석 토큰이 있다면 다른 공개 페이스트와 똑같이 — 민감한 값은 먼저 지우고 넣으세요.

실제로 어떤 종류의 HTML 오류를 고치나요?

닫히지 않은 태그(<p>, <li>, <td>, <span>), 일치하지 않는 닫는 태그, 누락되거나 짝이 안 맞는 속성 따옴표, 잘못된 DOCTYPE, 본문에 떠도는 엔티티여야 할 &·<·>, 그리고 명백한 중첩 실수(인라인 요소 안의 블록 요소). 누락된 콘텐츠를 만들어내거나 유효한 마크업을 다시 쓰지는 않습니다.

클래스, id, 인라인 스타일이 바뀌나요?

아니요. 수정 도구는 구문만 고치도록 명시적으로 지시받습니다 — 클래스 이름, id, 인라인 style 속성, data-* 속성, onclick 같은 이벤트 핸들러는 그대로 통과시킵니다. 출력에서 그중 하나라도 변경된 것처럼 보인다면 그건 버그입니다.

HTML5를 만드나요, XHTML인가요, 둘 다인가요?

HTML5를 목표로 합니다 — 현행 모든 브라우저가 파싱하는 표준이 그것이니까요. <br /> 같은 void 요소의 자체 닫는 태그는 입력으로는 받지만 출력은 표준 HTML5 형식을 씁니다. 엄격한 XHTML 출력이 꼭 필요하다면(요즘은 드물죠) XHTML 전용 도구를 쓰세요.

그냥 W3C 검증 도구에 돌리면 안 되나요?

마무리 검사로는 그래야죠 — 무엇이 유효한 HTML인지에 관한 진실의 원천은 W3C 검증 도구입니다. 다만 오류를 한 번에 하나씩만 보여주고 고쳐주지는 않습니다. 이 수정 도구는 한 번에 문서를 닫아 놓고 싶을 때 먼저 쓰는 도구이고, 그다음 검증 도구로 확인하면 됩니다.

접근성은요? 누락된 alt나 ARIA를 추가해 주나요?

아니요, 의도적입니다. ARIA 역할alt 텍스트는 콘텐츠 결정이지 구문 결정이 아닙니다. 자리만 채우는 alt=""를 넣으면 진짜 접근성 문제를 가리게 됩니다. 그건 전용 a11y 감사(axe, WAVE, Lighthouse)로 돌리세요.

함께 쓰면 좋은 HTML 도구

구문을 고치는 건 시작일 뿐입니다. 일단 파싱이 되면 다음 단계로 유용한 도구들입니다: