HTML Table Generator - From CSV or Excel, With Preview

Anatomy of a proper HTML table

A minimal table is <table>, rows of <tr>, and cells of <td>. A good table adds structure: <thead> around the header row, <th> for header cells with scope="col" so assistive technology knows which column each header labels, <tbody> around the data, and an optional <caption> that says what the table shows. Browsers render the plain and structured versions almost identically. Screen readers, search engines, and anyone styling the table later do not.

The generator always writes the structured version. Your CSV's first row becomes the header (untick the box if your data has no header), every cell is HTML-escaped, and short rows are padded with empty cells so every row has the same number of columns.

Worked example: a pricing table

Paste four rows copied from a spreadsheet: Plan, Price, Storage as the header, then Free, $0, 5 GB; Pro, $12/mo, 100 GB; and Team, $49/mo, 1 TB. The output is a table with a thead holding three th cells and a tbody with three rows of three td cells, 10 lines of clean markup, ready for a CMS HTML block.

Add a caption such as "2026 pricing plans" and it appears as the first child of the table. Tick Inline styles and each cell gets a 1 px border and padding written directly on the element, with border-collapse on the table, which is what you need for email.

Tables in HTML email

Email is where tables still matter most. Outlook for Windows renders email with Microsoft Word's engine, which ignores much of modern CSS, and several webmail clients strip or rewrite <style> blocks. Inline style attributes on each cell are the one approach that works nearly everywhere, which is why the inline option exists.

Keep email tables simple: explicit borders and padding, no CSS grid or flexbox, and widths in pixels or percentages on the table itself. Test in at least Gmail, Outlook, and Apple Mail before sending to a large list.

Accessibility and SEO

The W3C's table tutorial is clear on the basics: mark header cells with th, associate them with scope, and give complex tables a caption. With those in place, a screen reader announces "Price, $12/mo" instead of reading an unlabeled stream of values. The generator adds scope="col" to every header cell automatically.

Search engines read tables too. Google sometimes pulls well-structured HTML tables into featured snippets for comparison queries ("X vs Y price"), and a clear header row makes that more likely. Tables built from images or div soup cannot be read at all.

Do not use tables for page layout. That practice died with CSS layout in the 2000s, and it confuses screen readers, which announce row and column counts for every layout cell.

Making tables work on phones

Wide tables overflow small screens. The simplest fix is a wrapper: put the table inside <div style="overflow-x:auto"> so it scrolls sideways within the page instead of pushing the whole layout wider. For three or four short columns, most tables fit a 375 px phone screen without help. For more columns, consider whether some belong in a second table, or whether a list of cards reads better on mobile.

Common mistakes

Splitting CSV on commas by hand. "Portland, OR" becomes two cells. The parser handles quoted fields, so it stays one.

Pasting unescaped text. A cell containing <b> or & can break the table or inject markup. Every cell here is escaped.

Using rowspan and colspan for simple data. Merged cells make tables harder to read for screen readers and harder to maintain. Use them only when the data truly has grouped headers, and add them by hand after generating.

Styling with the old border="1" attribute. It still works in browsers but is obsolete in HTML5. Use CSS or the inline style option instead.