Free · Fast · Privacy-first

Format HTML Table Code Online

HTML tables are among the most structurally complex elements in the language, and they suffer the most from poor formatting.

⚡

Correctly indents all table elements at their nesting depth

🔒

Handles thead, tbody, tfoot, colspan, and rowspan markup

✨

Makes row and column structure immediately visible

⚡

Free with no installation required

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this HTML Formatter to your website

Drop the HTML Formatter into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/html/html-formatter?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="HTML Formatter by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/html/html-formatter?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="HTML Formatter by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Why HTML Tables Need Careful Formatting

HTML tables have a multi-level element hierarchy that is unique in the language. A table contains thead, tbody, and tfoot section elements; each section contains tr row elements; each row contains th and td cell elements; and each cell can contain arbitrary nested HTML. A medium-sized data table can produce four or five nesting levels before you even start counting the content inside the cells. Without correct indentation at every level the boundaries between rows blur into the boundaries between cells, and the only way to verify that a row has the expected number of cells is to count tags one at a time, which is the kind of work no human should do when a parser can do it for them.

FixTools indents table elements according to the canonical HTML5 table model. The table opens at whatever nesting depth its surroundings dictate. The thead, tbody, and tfoot sections each get one level deeper. The tr elements inside those sections get two levels deeper than the table. The th and td cells inside the rows get three levels deeper. Nested tables, which appear in legacy email templates and some CMS exports, get treated as full subtree elements within their containing cell and carry the indentation forward from there. The result is markup where the visual depth of any line tells you exactly what role the element plays in the table structure.

A common source of table rendering bugs is structural inconsistency that is invisible in unformatted markup. A row that has one extra cell will misalign every column to its right; a colspan value that doesn't add up to the total column count will produce phantom or missing cells; a th that should be a td will confuse screen readers about which elements are headers and which are data. All three of these problems jump out of formatted table markup because the indentation makes the cell count per row immediately countable. They are nearly impossible to spot in unformatted markup, which is why many table debugging workflows now start with a formatting pass before any other investigation.

For accessibility specifically, the value of formatted table markup is even higher. WCAG 2.1 requires data tables to have proper header associations, achieved either through scope attributes on th elements or through headers attributes on td elements pointing to th ids. Auditing whether these associations are correct on a non-trivial table is genuinely difficult on compressed markup and genuinely straightforward on formatted markup, because the formatted version puts every th and td in clear context where the attributes are easy to scan. Accessibility audits on table-heavy pages routinely take a fraction of the time on formatted source compared to unformatted source.

MDN: HTML table basics HTML Living Standard: Table model

How to use this tool

💡

Paste any HTML containing tables and click Format. Every table element is indented to the correct depth, making the row and column structure clear at a glance.

How It Works

Step-by-step guide to format html table code online:

1
Paste your table HTML
Paste any HTML containing one or more tables into the input panel. The formatter handles single tables, multiple tables on the same page, and nested tables within table cells.
2
Click Format
Click Format. Table elements are indented at the correct depth for their level in the table hierarchy, with thead, tbody, tfoot, tr, th, and td each at their expected position.
3
Verify row and column structure
Scan the formatted output to verify that each tr contains the correct number of td or th cells and that thead, tbody, and tfoot sections are correctly placed. The indentation makes any anomaly stand out.
4
Copy the formatted HTML
Copy the formatted output and use it in your editor, paste it into documentation, or use it as the basis for further debugging or accessibility review.

Real-world examples

Common situations where this approach makes a real difference:

Debugging a pricing comparison table

A six-column, fifteen-row pricing table has a rendering misalignment that appears only in Firefox. The developer formats the 18KB table HTML and within seconds spots a missing td in row nine of the comparison data, which causes every cell to its right to shift one column over. The bug had survived three rounds of code review because no reviewer was willing to count cells in compressed markup. The formatted output made the missing cell unmissable.

Formatting a data table exported from Excel

An Excel-to-HTML export produces a single-line 42KB table for a financial report. Formatting reveals that the export omitted the thead section entirely and replaced every th with a td, breaking screen reader navigation of the column headers. The team fixes the export pipeline to emit proper header markup before the report ships, catching the accessibility issue weeks before it would have hit production.

Preparing a financial report table for accessibility review

A 200-row financial summary table goes into accessibility review before publication. The team formats the table first, and the reviewer notices in the first ten minutes that scope attributes are missing on every column header. Adding the scope attributes takes a quarter of an hour. Without formatting, the same issue might have been missed during the audit or might have taken hours to identify across the unformatted source.

Reviewing an email template with layout tables

A legacy HTML email template for a monthly newsletter uses nested tables for layout because the recipients include older email clients that don't support CSS grid. Formatting the 55KB template reveals four levels of table nesting and three inner tables with incorrect column counts that were producing rendering glitches in Outlook. All three issues are fixed in a single session before the campaign sends.

When to use this guide

Use this when you need to read, edit, or debug HTML tables that are compressed or inconsistently indented, making it hard to verify row and column structure.

Pro tips

Get better results with these expert suggestions:

Use formatting to debug responsive table issues

Responsive table strategies such as horizontal scrolling at narrow widths, stacking rows as cards on mobile, or hiding lower-priority columns all depend on the underlying table structure being correct before any CSS can do its work. Formatting the table HTML first lets you verify the structural assumptions your responsive CSS depends on. A misplaced th or an inconsistent colspan that breaks responsive behavior is much easier to find in the formatted source than in the unformatted source, and a quick formatting pass should be the first step in any responsive table debugging session.

Format before auditing table accessibility

WCAG 2.1 success criteria for data tables include requirements for headers, captions, and the association between headers and cells. Auditing whether a table meets these requirements is far easier on formatted markup. Each th sits in clear context with its scope attribute visible, each td shows its headers attribute if it has one, and the caption element if present is unmissable at the top of the table. Plan to format every table you audit, and the audit itself will move from a tedious counting exercise to a straightforward review.

Format nested tables with care

Nested tables are strongly discouraged in modern web development and have been since the move away from table-based layouts in the mid-2000s. They still appear in legacy email HTML, where modern layout techniques such as CSS grid are not reliably supported, and in some older CMS exports. When formatting nested tables, the inner table adds three or four more indent levels on top of the outer table's nesting. If the resulting indentation pushes content past the right edge of your editor, treat that as a signal: the nesting may be reducible, and a quick refactor can simplify both the markup and the maintenance burden.

Use formatted table output to generate spreadsheet exports

When extracting tabular data from an HTML table for use in a spreadsheet or analysis tool, format the HTML first so the row and cell boundaries are visible. The formatted structure makes it trivial to write a small script that walks the rows and emits CSV, and it also makes manual extraction far less error-prone if scripting isn't available. Without formatting, the cell-to-cell boundaries in compressed source are easy to miscount, and the resulting export ends up shifted by one column.

Format tables to verify colspan and rowspan

After formatting, count the effective cell count per row by checking how many td/th elements appear at the third indentation level within each tr. Cells with colspan span multiple columns and should match the table's column count when summed.

Use scope attributes for accessible tables

After formatting makes your table structure visible, review th elements for scope="col" and scope="row" attributes. Correctly scoped headers are required for screen reader accessibility in data tables.

Format before converting tables to CSS grid

When migrating a layout table to CSS grid, format the table HTML first to clearly see the structure you are replacing. The formatted output shows exactly which cells span multiple columns or rows.

FAQ

Frequently asked questions

Table elements are indented according to their depth in the table hierarchy. The table element sits at whatever depth its surroundings provide. The thead, tbody, and tfoot section elements are one level deeper than the table. The tr row elements are one level deeper than their section. The th and td cell elements are one level deeper than their row. Any nested table inside a cell adds further depth from that point, with the same rules applied recursively. The result is markup where the depth of any line directly reflects its role in the structure.

Yes, colspan and rowspan are attribute values like any other and are preserved exactly as written. The formatter handles the structural indentation of the table correctly regardless of span values. Verifying that span values produce the expected layout requires visual inspection of the formatted output, because the formatter doesn't evaluate whether the column-and-row math actually works. A common debugging workflow is to format the table, then count the effective columns per row to confirm the spans add up, which is far easier on formatted markup than on the original.

Yes, all three table section elements are recognized and indented at the correct depth within the table structure. The tbody element is implicitly present even when omitted in the source, because the HTML5 specification requires browsers to insert it automatically during parsing. The formatter follows the same rule and indents tr elements as if they were inside a tbody even when the section element is missing from the source, which produces output that matches what the browser would actually render.

No, formatting reveals structural problems but does not fix them. If a table has a missing td that causes column misalignment, an incorrect colspan that breaks the column count, or a misplaced closing tag that breaks the nesting, the formatted output will show the resulting indentation anomaly clearly, but you will have to fix the underlying problem manually. This is the right behavior: silently correcting structural problems would produce surprising changes that obscure the original intent of the source. Formatting makes problems visible; fixing them is your job.

FixTools handles large tables without difficulty because the formatting runs in your browser's JavaScript engine, which can process megabytes of HTML in milliseconds. For tables with hundreds or thousands of rows, one effective strategy is to format the entire table at once and then use your editor's search function to scan for structural anomalies. Another is to format just the header section and a few representative rows as a structural template, then verify that the remaining rows match the same pattern. Both approaches work well, and the choice depends on whether you suspect specific rows are problematic.

Yes, email HTML commonly uses tables for layout because many email clients still do not reliably support CSS grid or flexbox. FixTools formats nested layout tables correctly, indenting each nested level further than its parent so that the layout structure becomes visible. This makes even deeply nested email table structures readable, which is essential when debugging rendering issues that appear only in specific email clients such as older Outlook versions or certain mobile mail apps.

No, tables should be reserved for tabular data. For page layout, CSS grid and flexbox are the correct choice in any context where they are supported, which today means essentially all websites. Tables-for-layout was a technique that emerged in the late 1990s when CSS layout was too limited to handle real designs, and it persisted into the mid-2000s before CSS layout matured enough to replace it. The only modern context where layout tables remain reasonable is HTML email, where many clients still lack CSS layout support.

Yes, and this is one of the higher-value uses of the formatter for legacy maintenance work. Formatting the table HTML first makes the row and column structure visible, which gives you a precise map of what your CSS grid template needs to replicate. Each formatted tr corresponds to a grid row, each td corresponds to a grid item, and any colspan or rowspan values translate directly to grid-column-span or grid-row-span declarations. The formatted structure is your migration plan, and following it row by row makes the conversion straightforward.

Yes, the caption element is preserved and placed on its own line inside the table at the correct depth, which matches the structural position required by the HTML5 specification. The summary attribute, although deprecated in HTML5, is preserved if present because removing attributes silently would change behavior in ways that could break legacy assistive technology setups. For new tables, use caption for table descriptions and aria-describedby pointing to an external description element instead of the deprecated summary attribute.

Formatting is the first step that makes accessibility work practical. Once the table is formatted, walk through it adding the elements and attributes needed for accessibility: a caption element describing what the table contains, scope="col" on every th in the thead, scope="row" on any th elements that serve as row headers in tbody, and abbr attributes on th elements where the visible header text is too long to repeat in every cell. The formatted source makes each of these additions easy to place correctly. Validate the result with an accessibility checker afterwards to confirm everything is in order.