CSV to HTML Table

Only into one that converts in your browser. Price lists, customer exports and internal reports are the typical input, and an upload-based converter keeps a copy of every one of them. The conversion runs here as JavaScript inside your tab, so nothing is uploaded or logged, and the page works offline. For any other tool, open the Network tab in devtools and convert a dummy file first: if a request goes out, so does your data.

Generate the markup once instead of parsing the file in the browser. Static table markup pasted into the page is smaller, renders on the first paint and is indexable, while a runtime fetch plus a JavaScript parser costs a request, a library and a layout shift, and search engines see an empty container until the script runs. Convert the CSV to a table when the data changes on a release cycle, which covers price lists, comparisons and documentation. Load and parse at runtime only when the file is genuinely dynamic (an export that updates hourly, a dataset too large to inline), and then render server-side if your stack allows it.

A <table> containing a <thead> with one row of <th scope="col"> header cells, and a <tbody> of rows with <td> cells. That structure, which this converter emits, is what HTML defines for tabular data; screen readers use it to announce the column a cell belongs to, and CSS and JavaScript libraries hook into thead/tbody for sticky headers, striping and sorting.

It tells assistive technology which cells a header governs: scope="col" for a column header, scope="row" for a row header. Sighted users infer this from position; a screen reader announcing a single cell cannot, so it reads the associated header along with the value. It costs nothing and is the single cheapest accessibility win in table markup, which is why this converter includes it on every header cell.

Escape every cell before it becomes markup. A value containing < or & is read as the start of a tag or an entity, so one product description with a <div> in it swallows the rest of your table, and a column fed from user input is the textbook route for stored XSS. Escaping turns < into &lt; and & into &amp;, which renders the characters and builds nothing. Do it in the generator or in the template (textContent instead of innerHTML, auto-escaping in Twig, Blade or Jinja), never with a regex that strips tags, because that misses attribute contexts and encoded payloads. Every cell in the output above is escaped for exactly this reason.

Three rules carry most of the way: border-collapse: collapse on the table, padding on th and td (0.5em 0.75em is a sane start), and a border-bottom on rows rather than full grid lines. Add text-align: right for numeric columns and a stronger bottom border under the thead. Because the converter emits clean thead/tbody structure, frameworks work too: Bootstrap needs class="table", Tailwind styles it with a handful of utilities.

Static HTML alone cannot sort, but the emitted structure is exactly what sorting libraries expect. Lightweight options like sortable or tablesort attach to any table with a proper thead; DataTables adds paging and filtering. Progressive enhancement applies: the table is complete and readable without JavaScript, and a library upgrades it where scripts run.

Pick one of three approaches, because none of them is right for every table. Horizontal scrolling is the honest default: wrap the table in a div with overflow-x: auto and let the columns keep their width, which preserves the grid and works with any number of columns. Card stacking turns each row into a block on narrow screens, using CSS to hide the header row and data-label attributes to repeat the column name next to each value; it reads well for two or three columns and falls apart beyond that. Dropping columns below a breakpoint is the third option and the one to be careful with, since content hidden on mobile is still downloaded and is invisible to the person who needs it most. Whatever you choose, keep the table markup intact and solve it in CSS, so screen readers still get the row and column relationships.

For data, a table. The rule from the HTML spec is about meaning: tabular data (rows and columns whose intersection carries meaning) belongs in <table>, layout belongs in CSS. Divs styled into a grid lose the semantics screen readers and search engines rely on, and re-implementing sticky headers and cell association by hand is more work, not less. Layout tables are the anti-pattern; data divs are the mirror image.

They become <br> tags, so a multi-line address renders as multiple lines inside one cell. The quoting in the CSV (line breaks are only data when the cell is quoted) decides what is a row break versus an in-cell break, and this parser follows RFC 4180 on that distinction.

Browsers render tens of thousands of rows, but users scroll away long before that, and every row is DOM weight. Beyond a few hundred rows, consider pagination, a search filter, or keeping the data as a downloadable CSV with a summary table on the page. As a data point, a 1000-row, 6-column table from this converter is roughly 150 KB of HTML, which is more than most entire pages.