Convert CSV to HTML
Turning a data file into a web table by hand is where the ampersands and the angle brackets get you. This conversion parses the CSV properly, so a field containing a comma stays one cell, and escapes the characters that would otherwise close a tag early or render as markup.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeDrop your CSV file here, or click to browse
Up to 50 MB. Deleted automatically after 30 minutes.
What it does
- Quoted fields containing commas and line breaks parse as single cells
- Ampersands, angle brackets and quotes are escaped for safe markup
- Output is a plain table element with no styling attached
How to use CSV to HTML
- 1
Upload the CSV
With or without a header row. Quoting is handled to the usual rules, including doubled quotes inside a quoted field.
- 2
Rows become table rows
Each line becomes a row and each field a cell, producing a table that a browser renders correctly without further work.
- 3
Style it where it lands
The markup carries no classes or inline styles, so it inherits whatever the destination page applies.
How it works
The CSV is parsed with full quoting rules rather than split on commas. A field wrapped in quotation marks may contain commas, line breaks and doubled quotes, and all three have to survive as part of one cell.
Each parsed row is then emitted as a table row and each field as a cell, with the four characters that matter in markup — ampersand, less-than, greater-than and quote — replaced by their entity equivalents.
The two failures this avoids
The shifted column. One product name containing a comma, split naively, becomes two cells, and every column to its right moves over by one for that row alone. On a table of forty rows this is genuinely hard to spot.
The swallowed table. A field containing a less-than sign, emitted unescaped, starts what the browser reads as a tag. Everything after it up to the next greater-than sign disappears from the rendered page.
Why the output has no styling
Because it is going into a page that already has opinions. A table arriving with its own classes and inline colors has to be stripped before it fits, which is more work than styling plain markup. What comes out is structure, and the destination supplies the appearance.
When a spreadsheet is the better target
If the data is going to be sorted, filtered or calculated on, convert to XLSX or ODS instead. An HTML table is for reading. It has no formulas, no sorting and no types, and turning one back into data means parsing it again.
Where the markup usually needs help
What comes out is a plain, correct table: a table, a header row, and a cell per
field. It carries no classes, no styling and no responsive behavior, because
none of that can be inferred from a CSV — the file contains values and nothing
about how they should look.
That is the right default for pasting into a page that already has its own styles, and it is not enough on its own. A wide table on a phone will overflow unless the page wraps it in something that scrolls, and a long one usually wants a sticky header. Both are decisions about the page rather than about the data, which is why they are left to you.
Examples
A price list for a documentation page
A naive split on commas would have turned that one product name into two cells and shifted every column after it. Proper parsing is the whole value of converting rather than pasting.
Data containing markup characters
The less-than and the ampersand are escaped, so the browser shows the characters instead of trying to parse a tag. Unescaped, that row would have swallowed the rest of the table.
Frequently asked questions
Why not just paste the CSV into a table by hand?
Because of quoting and escaping, which are the two things a manual paste gets wrong. A field containing a comma has to stay one cell, and a field containing an ampersand or an angle bracket has to be escaped or the browser will try to interpret it as markup. Both failures are silent: the page renders, it is just wrong, and on a long table nobody notices which row shifted.
Does the first row become a header?
The rows are emitted in order, so if your CSV starts with column names they appear as the first row of the table. CSV itself has no way to mark a header, so the conversion cannot know for certain that a first row is labels rather than data. Promoting it to a header row in the markup is a one-line change once the table is in your page.
Is the table styled?
No, deliberately. The output is plain markup with no classes, inline styles or attributes beyond the table structure itself, so it takes on whatever the destination page already applies to tables. Emitting styling would fight with the site it lands in and would have to be stripped by whoever pastes it.
Further reading
- Exported as HTML, the Table Was Sixteen Times the CSVExporting a spreadsheet to HTML is the quickest way to put a table on a page, and it produces a file that dwarfs every other format the same data fits in. Knowing where the weight comes from tells you when the export is fine and when it will cost you a page load.
- The Same Table Was Three Times Bigger as JSONCSV writes each column name once, at the top. JSON writes it again on every single row. On a table of any size that is not a subtlety — it is the dominant term, and it explains both why the conversion inflates and why it barely matters over the wire.
- The Three Invisible Bytes at the Start of Your CSVYour CSV has a column called `id`. Your code looks for a column called `id`. It is not there. Print the header and it says `id`. The problem is three bytes at the very start of the file that no editor displays, that Excel on Windows once needed, and that half the software in the world now has to work around.