Overview
Pulls every <table> out of pasted HTML and converts it to clean CSV, JSON, or a GitHub-flavored Markdown table. Headers are detected from the first row of <th> cells (or synthesised as Column 1..N), captions are preserved, and when a page contains several tables a dropdown lets you pick which one to convert. Everything runs in your browser - paste scraped HTML without sending it anywhere.
How It Works
Paste the HTML source - a full page, a fragment, or the view-source of a table - into the left panel. The tool reports how many tables it found and shows the first one converted in your chosen format: CSV for spreadsheets, JSON as an array of header-keyed objects, or Markdown for documentation. Switch tables from the dropdown when the page has more than one.
Step-by-Step Usage Guide
- Copy the HTML - view-source on the page, or the outerHTML of the table element.
- Paste it into the HTML panel; the first table converts immediately.
- Pick CSV, JSON, or Markdown depending on where the table is going.
- If several tables were found, choose the one you need from the dropdown before copying.
Technical Specifications & Standards
Parsing uses the browser's own HTML parser (DOMParser), which means the tool's interpretation of nested tags, entities, and malformed markup is exactly what a browser would do - the same engine that rendered the page you scraped from. Cell text is extracted as textContent, so inline markup like <b> or nested <span> collapses to plain text and HTML entities such as & arrive already decoded. Header detection follows the common convention: if any cell in the first row is a <th>, that row is the header and the rest are data; otherwise no header row is assumed and Column 1..N names are generated rather than eating a data row. The Markdown output pads columns for readability and escapes pipe characters, since an unescaped pipe inside a cell would break the GFM table it lands in. The known limitation is stated up front: colspan and rowspan cells are read as their own text, because reconstructing merged layouts requires the visual grid, not the DOM.
Targeted Use Cases
- Getting a pricing or comparison table from a web page into Excel without retyping it.
- Converting an HTML email table into CSV data your tooling can actually read.
- Turning documentation tables into Markdown for a README or wiki.
- Checking that a scraping selector's table really contains the rows you expect.
Notes & Gotchas
- Prefer tables with real <th> headers - synthesised Column 1..N names lose the semantics of the original.
- Clean merged-cell layouts in the source page first; colspan data needs a human decision about what each merged cell means.
- For spreadsheets, use CSV; for documentation, Markdown - converting twice loses less than hand-editing either format.
- Watch numbers that contain thousands separators like 1,240 - CSV keeps the comma inside quotes, but your spreadsheet's locale may parse it differently.
Frequently Asked Questions
Is the HTML uploaded anywhere?
No. Parsing happens with your browser's own DOMParser on your machine. Scraped content, internal pages, and anything confidential stays local.
Why does my table with colspan look wrong?
Cells that span multiple columns are read as single cells; the grid positions they visually occupy are not reconstructed. Flatten merged cells in the source, or reorganise the table, for a faithful conversion.
How are headers decided?
If the first row contains <th> cells it is treated as the header; otherwise Column 1..N names are generated and every row stays data. This avoids swallowing a real data row as a header.
Does it handle nested tables?
Each <table> element in the document is extracted independently, so a nested table appears as its own entry in the dropdown rather than being tangled into the parent's rows.