HTML 포매터

An HTML formatter takes a document or fragment and re-indents it so the tree structure is visible: each element starts on its own line, attributes line up, and the nesting depth tells you which container owns which content. It does not change which elements exist, what attributes they carry, or how the browser will render them — it only changes how the markup looks when a human reads it.

Why HTML in the wild rarely arrives indented

Production HTML is usually compiled from templates, generated by a CMS, or copied from rendered output. Whitespace between elements is mostly ignored by the renderer but takes bytes, so build pipelines routinely strip it. By the time a maintainer needs to read the markup — to debug a layout, audit a snippet for accessibility, or extract a component — the structure has to be reconstructed visually. A formatter does that mechanically.

What the formatter changes, what it must keep identical

Formatting touches whitespace between elements, indentation depth, and attribute alignment. It must not change the element tree, attribute names, attribute values, text content, comments, or anything inside <pre>, <textarea>, <script>, and <style>, where whitespace is semantically significant.

• Block-level elements each start on their own line so the document outline reads like an outline.
• Children indent one level deeper than their parent, with consistent space-or-tab width.
• Inline elements stay inline unless they make a single line unreadable, so prose does not get torn into one-word lines.
• Whitespace inside <pre>, <textarea>, <script>, and <style> is preserved verbatim — those areas are off-limits.
• Attribute order, attribute values, and HTML entities are kept exactly as-is — encoding decisions belong to authors, not to a formatter.

Rule of thumb: formatting must leave the rendered page byte-for-byte identical. If indenting your HTML changes how the page looks in a browser, something other than formatting is going on.

이 도구 사용 방법

1. Prepare representative HTML fragments and copied markup that need clean review-friendly structure in HTML 포매터 instead of starting with the largest or most sensitive real input.
2. Run the workflow, generate formatted HTML that is easier to review before publishing or embedding, and review nesting depth, attributes, entity text, inline scripts, inline styles, and whether the source is really HTML rather than escaped text before deciding the result is ready.
3. Only copy or download the result after it fits template review, CMS cleanup, snippet sharing, and docs examples and no longer conflicts with this constraint: Formatted HTML can still be semantically wrong or unsafe, so review the markup in its real rendering context before publishing.

HTML 포매터 예시

이 예시는 HTML 포매터가 처리하도록 설계된 대표 입력 형태와, 자신의 작업 흐름에 복사하기 전에 기대할 수 있는 결과 모양을 보여 줍니다.

예시 입력

<main><h1>Tools</h1><p>Fast utilities.</p></main>

예상 출력

<main>
  <h1>Tools</h1>
  <p>Fast utilities.</p>
</main>

A compacted snippet, restored to a reviewable tree

<!-- before — typical of CMS or build output -->
<article class="card"><header><h2>Title</h2><p class="meta">Updated today</p></header><section class="body"><p>Lead paragraph that summarises the article.</p><ul><li>First point</li><li>Second point</li></ul></section></article>

<!-- after — easy to scan and diff -->
<article class="card">
  <header>
    <h2>Title</h2>
    <p class="meta">Updated today</p>
  </header>
  <section class="body">
    <p>Lead paragraph that summarises the article.</p>
    <ul>
      <li>First point</li>
      <li>Second point</li>
    </ul>
  </section>
</article>

Where reformatting HTML pays for itself immediately

HTML is read by far more people than write it. The list below collects the situations where having a clean, indented version of the markup is the difference between a five-minute task and an hour of squinting.

• Reviewing a CMS-generated page when an editor reports a layout problem and you only have the rendered HTML.
• Extracting a component from a static-site build, where everything came out of the pipeline already collapsed.
• Comparing two snapshots of the same page across deploys to see what really changed in the DOM.
• Auditing accessibility — landmark structure, heading order, and ARIA attributes are far easier to verify on an indented tree.
• Teaching or documenting HTML — readers cannot internalise nesting from a single-line dump, but they can from a tree.

Edge cases worth understanding before you format

Most HTML formatters are conservative on purpose because HTML hides a few traps that other formats do not have. Walking through them once makes it much easier to tell whether a surprising diff is a bug or a deliberate decision.

• Whitespace inside <pre>, <textarea>, <code> with white-space: pre, and inline blocks like <span> can change layout — these must not be touched.
• Self-closing markers like <br/> vs <br>: HTML5 treats them the same, but XHTML and some template engines do not. A formatter should keep whatever the source used.
• Conditional comments and templating placeholders (<!--[if IE]-->, {{ }}, {% %}, <?= ?>): these are not real HTML but pass through the formatter unchanged.
• Inline scripts and styles: their contents are JS or CSS, not HTML. Do not let an HTML formatter recursively reformat them; use the dedicated formatters for those languages.
• Whitespace-sensitive layouts: stacking `<span>` chips inline often relies on the space between tags. Forcing each into its own line can collapse the row in the rendered page.

HTML formatter vs related tools

실무 참고

• 원본 HTML 내용이 길거나 운영 환경에 바로 들어갈 예정이라면, 먼저 작은 조각으로 시험한 뒤 전체에 적용하는 편이 안전합니다.
• 포맷팅과 압축은 표현 방식과 크기를 바꿀 뿐이며, 실제 lint, 파싱, 실행 검사를 대신하지는 않습니다.
• SQL이나 스크립트처럼 실행 가능한 결과는 실제 환경에 적용하기 전에 반드시 다시 검토하세요.

HTML 포매터 참고 정보

HTML 포매터는 포맷팅이 HTML 조각을 어떻게 바꾸는지와, 결과를 다른 환경에 붙여넣기 전에 무엇을 확인해야 하는지 설명합니다.

• 포맷팅은 가독성을 높이는 데, 압축은 payload 크기와 임베딩 효율을 줄이는 데 더 초점을 둡니다.
• 처리 후에는 따옴표, 주석, 세미콜론, 여러 줄 콘텐츠를 먼저 확인하세요.
• SQL이나 스크립트처럼 실행 가능한 출력은 실제 환경에 적용하기 전에 반드시 다시 검토하세요.

참고 자료

• WHATWG HTML Living Standard
• MDN: HTML