How to Convert Markdown Table to HTML Online

The 10-Second Answer: Paste, Convert, Copy

Here is the whole workflow: copy your markdown table, paste it into our free markdown to HTML converter, and copy the resulting HTML. A table written as | Name | Price | on one line, | --- | --- | on the next, and | Widget | $9 | below it comes out as a proper <table> with a <thead> holding <th> header cells and a <tbody> holding <tr> rows of <td> data cells — semantic, accessible HTML with zero hand-coding. The converter needs no account, runs entirely in your browser, and preserves everything else in the document (headings, lists, links) while it converts the tables. This is the fastest path when you have a README, a Notion export, or a GitHub wiki page and you need real HTML for a CMS, an email template, or a static site. The rest of this guide covers the syntax so you can write tables correctly in the first place, fix the ones that break, and understand exactly what the converter does with each row.

Markdown Table Syntax: The Crash Course

A markdown table is built from three ingredients. Ingredient 1: the header row — cells separated by pipes: | Product | Price | Stock |. The outer pipes are optional but recommended; they make the table readable in raw text. Ingredient 2: the delimiter row — this is the magic line that tells the parser 'this is a table': | --- | --- | --- |, one dash-group per column (three or more dashes is conventional; a single dash technically works in most parsers but looks broken). Ingredient 3: the body rows — one line per row, same pipe structure: | Widget | $9 | 42 |. Column counts must match across all three ingredients: a body row with four cells under a three-column header produces garbage in most renderers. Cells can contain inline formatting — bold, italic, [links](url), and `code` all work inside table cells, and they convert to their HTML equivalents (<strong>, <em>, <a>, <code>) nested inside the <td>. Blank lines end the table, so keep your rows contiguous. That is the complete syntax — three row types, pipes between cells, no closing tags, no attributes.

Column Alignment: The Colons Trick

By default every column aligns left, but the delimiter row accepts alignment markers: put a colon on the left for left-align (|:---|), on both sides for center (|:---:|), and on the right for right-align (|---:|). A price column written as | ---: | converts to <th align="right"> or, in cleaner modern output, a style="text-align:right" attribute — either way the numbers line up on the decimal point, which is the difference between a readable price table and a ragged one. Center alignment suits short status columns (✓/✗, yes/no); right alignment suits every numeric column you will ever make; left alignment suits names and descriptions. One caution: alignment is a hint, not a guarantee — some CMS rich-text editors strip align attributes on paste, so if your right-aligned numbers come out left-aligned in WordPress or an email client, the converter did its job and the editor ate the attribute. Re-apply alignment in the editor, or wrap the table in a class your stylesheet controls.

What the HTML Output Actually Looks Like

Understanding the output helps you style and debug it. Our converter turns the three markdown ingredients into this structure: the header row becomes <thead><tr><th>Product</th><th>Price</th></tr></thead>, and each body row becomes <tbody><tr><td>Widget</td><td>$9</td></tr></tbody>, all wrapped in <table>. The thead/tbody split is not cosmetic: screen readers announce <th> cells as headers for the column, which is what makes the table accessible, and CSS can target thead separately for sticky headers. Good converters also add scope="col" to header cells — the explicit accessibility attribute — and escape any raw <, >, or & inside cells so your cell text cannot break the page markup. If you are pasting the output into a stylesheet-driven site, the table inherits your theme's table styles automatically; if it renders unstyled, that means your theme has no table CSS, and a few lines of border/padding rules fix it. Compare this with hand-writing the same table in HTML: the markdown source is roughly a third of the characters, which is the entire reason the format exists.

Escaped Pipes and Other Syntax Traps

The pipe character is both the column separator and occasionally legitimate cell content — and that collision causes the most common broken tables. If a cell needs a literal pipe (a shell command like ls | grep x), escape it with a backslash: ls \| grep x — the parser then treats it as content, and the HTML output shows a plain |. Without the escape, the parser splits the cell in two and your column count breaks. Trap 2: the missing delimiter row. Without the | --- | line, most parsers render the whole thing as a paragraph with literal pipes — the single most common 'my table won't render' complaint, and the fix is always adding the delimiter. Trap 3: uneven rows. A body row with fewer cells than the header silently shifts every later cell left in some renderers and errors in strict ones; count your pipes. Trap 4: blank lines inside the table end it — a table split by an empty line becomes two tables, and the second one lacks a header. Trap 5: pipes inside code spans — backtick-wrapped content with pipes usually survives, but nested backticks plus pipes defeat naive parsers; when in doubt, test the exact table in the converter before shipping it.

Why Tables Are 'GitHub Flavored' Markdown

Tables were never part of John Gruber's original 2004 Markdown — the spec covered paragraphs, headings, lists, and links, and that was it. Tables arrived with GitHub Flavored Markdown (GFM) around 2012, when GitHub needed README files to document APIs with parameter tables, and the pipe syntax was borrowed from earlier implementations like PHP Markdown Extra. That history explains two quirks: first, 'markdown table support' really means 'GFM table support,' and a renderer that only implements original Markdown (some old CMS plugins, a few email tools) will show your table as literal pipe text — always check which flavor your target supports. Second, advanced table features never standardized: colspan/rowspan do not exist in GFM at all (you need raw HTML for merged cells), and neither do captions or footers. If your table needs merged header cells, skip markdown for that table and write the <table> by hand — markdown and raw HTML can coexist in the same document. For everything else, GFM tables plus a converter cover the job, which is why the format conquered READMEs, wikis, and docs sites.

The Copy-Paste Workflow: README to CMS

The most common real-world conversion runs from a developer doc to a published page: a parameter table lives in a GitHub README, and marketing wants it on the website. The workflow: copy the table block from the README (header + delimiter + rows, no surrounding prose unless you want it converted too), paste into the markdown to HTML converter, copy the HTML output, and paste it into your CMS's HTML/code view — not the visual editor, which will escape the tags into visible text. Three refinements make this painless. First, strip smart quotes and em-dashes if the table passed through Google Docs or Notion — those survive conversion fine as UTF-8, but some legacy CMS databases mangle them. Second, check relative links: a [docs](/api) link that worked on GitHub points at your CMS's /api path after conversion, which may not exist — convert to absolute URLs. Third, add a wrapper class if your site styles tables: wrap the output in <div class="table-wrap"> so long tables scroll horizontally on mobile instead of breaking the layout. Done right, a 40-row API table moves from README to live page in under two minutes.

Accessibility and Mobile: Tables Done Right

A converted table is only finished when everyone can read it. The converter's <th scope="col"> output covers the basics for screen readers, but three author-side choices matter more. One: keep tables narrow. A 9-column table is unreadable on a phone no matter how good the markup — split wide tables, or transpose them so attributes become rows. Two: never use tables for layout. It is 2026, but email templates and legacy CMS content still do this; layout tables announce as data tables to screen readers and confuse everyone. Three: give the table a caption or a preceding heading that says what the table shows — 'Pricing by plan, per month' — because a screen-reader user navigating by tables hears the caption before deciding to enter it. For responsive behavior, the standard pattern is a horizontally scrolling wrapper on small screens (overflow-x: auto) rather than squishing columns — readable, simple, and it preserves the semantic markup the converter produced. Tables that follow these rules rank better too: Google's crawlers parse semantic tables cleanly, which is part of why well-structured comparison tables keep winning featured snippets.

Convert Your Markdown Table Now — Free

Writing the syntax by hand builds understanding; the free markdown to HTML converter builds the HTML. Paste any GFM table — or a whole document — and get clean, semantic <table> markup with proper thead/tbody structure, escaped cell content, and alignment preserved. It lives on the ToolNest homepage with 130+ other free tools, including our full markdown conversion guide for non-table documents and the HTML special characters guide for the escaping rules that keep your markup valid. Learn the pipe syntax once, convert in seconds forever.