CSV to HTML Table: Parse, Preview & Render

CSV to HTML is a display problem before anything else. You have rows of text data and you need to show them as a real table, with proper headers, accessible semantics, and a clear read on what the file actually contains. The old server-side approach worked for the era, but the useful part of the problem is browser-side and language-agnostic.

This guide walks through a complete browser-side CSV preview: file input, size check, a parser that handles quoted fields, DOM-based table rendering, and the state management that makes the preview usable rather than just functional. When the preview graduates to a real import, the path leads into the SQL guide, where staged rows and transactions own the database boundary.

What Makes CSV Tricky

RFC 4180 defines a format that looks simple until a real file arrives from a client. Fields can contain commas if they are wrapped in double quotes. Fields can contain double quotes if those quotes are doubled inside the wrapper. Fields can contain line breaks inside quoted values. The spec is optional in practice, so spreadsheet exports often bend the rules in small ways.

Splitting every line on commas breaks the first time a cell contains "Melbourne, Australia". A real parser has to track whether it is inside a quoted field before deciding what the current comma means.

OWASP documents a separate injection risk: cells that begin with formula-triggering characters such as =, +, -, or @ can execute formulas when someone opens the exported file in a spreadsheet application. For a read-only browser preview, textContent handles this cleanly because the text stays text and never becomes markup or code. If you later add an export feature, decide what to do with formula-looking cells before the feature ships, since prefixing a single quote is common but changes the underlying data.

The HTML Structure

Build the form and output container in plain HTML. The accept attribute gives the file picker a hint about expected file types, but your code still needs to validate size and content independently.

<form class="csv-preview" data-csv-preview>
  <label for="csv-file">Choose a CSV file</label>
  <input id="csv-file" name="csv-file" type="file" accept=".csv,text/csv">

  <label>
    <input type="checkbox" name="first-row-header" checked>
    First row contains headers
  </label>

  <button type="submit">Preview table</button>
  <p class="csv-note">Files stay in this browser tab and are never uploaded.</p>
</form>

<div data-csv-output aria-live="polite"></div>

The aria-live="polite" attribute on the output container lets screen readers announce the table when it appears, without interrupting whatever the user was doing. That attribute costs you nothing and covers a real accessibility gap. Tell users clearly that the preview is local. CSV exports often carry names, prices, or internal data that someone should not assume is already shared.

Reading the File

The File API gives you the selected file object, and TextDecoder converts the raw bytes into text. Set a size limit up front so the tab never tries to render a hundred-thousand-row export.

const form = document.querySelector("[data-csv-preview]");
const output = document.querySelector("[data-csv-output]");
const MAX_BYTES = 1_000_000;

form?.addEventListener("submit", async (event) => {
  event.preventDefault();

  const file = form.elements["csv-file"].files[0];

  if (!file) {
    showMessage("Choose a CSV file to get started.");
    return;
  }

  if (file.size > MAX_BYTES) {
    showMessage("That file is too large for a browser preview. Try a smaller export.");
    return;
  }

  const bytes = await file.arrayBuffer();
  const text = new TextDecoder("utf-8", { fatal: false }).decode(bytes);
  const rows = parseCsv(text);
  const firstRowIsHeader = form.elements["first-row-header"].checked;

  renderCsvTable(rows, { firstRowIsHeader, caption: file.name });
});

function showMessage(message) {
  output.replaceChildren();
  const para = document.createElement("p");
  para.textContent = message;
  output.append(para);
}

The fatal: false option on TextDecoder keeps a preview going when the file has mixed or messy encoding, which happens often in older spreadsheet exports. If you are importing into a database later, reject on encoding errors at that stage rather than silently keeping garbled bytes.

Parsing CSV Correctly

The parser below handles the ordinary RFC-style cases: commas, quoted fields, doubled quotes inside quoted fields, CRLF line endings, and line breaks embedded in quoted values. Treat it as a teaching parser rather than a production library. When real money, inventory, or customer records flow through the import, use a well-tested CSV library or delegate parsing to the server.

function parseCsv(text) {
  const rows = [];
  let row = [];
  let field = "";
  let inQuotes = false;

  for (let i = 0; i < text.length; i++) {
    const char = text[i];
    const next = text[i + 1];

    if (char === '"' && inQuotes && next === '"') {
      field += '"';
      i++;
      continue;
    }

    if (char === '"') {
      inQuotes = !inQuotes;
      continue;
    }

    if (char === "," && !inQuotes) {
      row.push(field);
      field = "";
      continue;
    }

    if ((char === "\n" || char === "\r") && !inQuotes) {
      if (char === "\r" && next === "\n") i++;
      row.push(field);
      rows.push(row);
      row = [];
      field = "";
      continue;
    }

    field += char;
  }

  if (field !== "" || row.length > 0) {
    row.push(field);
    rows.push(row);
  }

  return rows;
}

The parser tracks whether it is inside a quoted field on every character, so a comma inside "Auckland, New Zealand" never splits the field. The doubled-quote check runs before the single-quote toggle so "" inside a quoted field becomes one literal quote rather than opening and closing a new quoted section.

Rendering the Table

Use DOM methods and textContent when building the table rows. String concatenation with innerHTML lets a cell containing <script>alert(1)</script> become actual markup rather than visible text. This is the same principle as the poll guide: the browser can do a lot for you, but only when you let text stay as text instead of treating it as markup.

function renderCsvTable(rows, { firstRowIsHeader, caption }) {
  output.replaceChildren();

  if (rows.length === 0) {
    showMessage("That CSV file appears to have no rows.");
    return;
  }

  const table = document.createElement("table");

  const tableCaption = document.createElement("caption");
  tableCaption.textContent = caption;
  table.append(tableCaption);

  const [firstRow, ...bodyRows] = rows;
  const dataRows = firstRowIsHeader ? bodyRows : rows;

  if (firstRowIsHeader) {
    const thead = document.createElement("thead");
    thead.append(buildRow(firstRow, "th"));
    table.append(thead);
  }

  const tbody = document.createElement("tbody");

  for (const row of dataRows.slice(0, 500)) {
    tbody.append(buildRow(row, "td"));
  }

  table.append(tbody);
  output.append(table);

  if (dataRows.length > 500) {
    const note = document.createElement("p");
    note.textContent = `Showing 500 of ${dataRows.length} rows. Use the SQL import for the full dataset.`;
    output.append(note);
  }
}

function buildRow(cells, cellTag) {
  const tr = document.createElement("tr");

  for (const value of cells) {
    const cell = document.createElement(cellTag);
    if (cellTag === "th") cell.scope = "col";
    cell.textContent = value;
    tr.append(cell);
  }

  return tr;
}

The scope="col" attribute on header cells gives screen readers a clear signal about which column each header belongs to. A <caption> gives the table a proper name, and <thead> and <tbody> separate structural roles so assistive technology can announce the table shape correctly before the user moves through the cells.

The 500-row cap is a usability rule rather than a technical limit. A browser can render a larger table, but reading raw CSV in a web page stops being useful well before that ceiling. If the reader needs the full dataset, the right next step is filtering, pagination, or a server-backed import flow.

CSS for the Preview

CSV exports often have column names and values that were designed for a spreadsheet, not a web page. Let the table scroll horizontally rather than forcing text into unreadable narrow columns.

[data-csv-output] {
  overflow-x: auto;
}

[data-csv-output] table {
  min-width: 36rem;
  border-collapse: collapse;
  font-size: 0.9rem;
}

[data-csv-output] caption {
  text-align: left;
  font-weight: 700;
  margin-block: 0.75rem;
}

[data-csv-output] th,
[data-csv-output] td {
  padding: 0.65rem 0.85rem;
  border: 1px solid #cbd5e1;
  text-align: left;
  vertical-align: top;
}

[data-csv-output] th {
  background: #f8fafc;
}

[data-csv-output] tr:hover td {
  background: #f1f5f9;
}

The data-csv-output attribute selector keeps these styles scoped to the preview container, so they do not bleed into any other table on the page. Keep the rest of the page layout in CSS separate from the table's own presentation rules.

Empty and Error States

A usable preview handles every state the user can reach: the successful table, the empty file, the oversized file, and the missing file. The showMessage function above handles the empty and error cases in text. You should also think about what the output looks like before the user has chosen a file.

Consider a short placeholder in the output container so the area does not look broken on page load:

<div data-csv-output aria-live="polite">
  <p class="csv-placeholder">Choose a CSV file above to see a preview here.</p>
</div>

.csv-placeholder {
  color: #64748b;
  font-style: italic;
}

That placeholder disappears the moment output.replaceChildren() runs with real content. The error messages from the file-reading step follow the same pattern: they go into the same output container, they use textContent, and the aria-live region announces them to screen readers without any extra work.

When a Preview Becomes an Import

A browser-side preview is the right tool when someone needs to inspect a file quickly before committing to an import. Once users want to filter rows, deduplicate values, join against existing records, or write data to persistent storage, the feature has outgrown what a preview can do well.

That is the boundary where the CSV should travel to a server. The CSV to SQL guide covers what happens on the other side: staged rows, prepared statements, validation per column, and transactions that keep the database consistent when a row fails mid-import. The preview gives the user confidence about what is in the file. The import gives the application a durable copy of the data.

The browser-side work you built here does not disappear at that point. The file input, the parser, and the rendered preview are still useful as a confirmation step before the user commits the upload. Show them the table, let them verify the column mapping, and then let the server take the validated bytes.

Frequently Asked Questions

Why does a CSV preview show different values than a spreadsheet does?

Because a spreadsheet reformats on open while a preview shows the file as written. Leading zeros on postcodes and product codes get dropped, long numbers turn into scientific notation, and ambiguous dates get reinterpreted. The preview showing the raw text is the accurate view.

Is it safe to display an uploaded CSV directly?

Only if you render it as text rather than markup. A cell can contain a script tag. Building rows with DOM methods and textContent, as above, keeps the value inert automatically. Concatenating the same value into innerHTML is what reintroduces the risk.

Should the first row of a CSV always be a header?

Not always, so do not assume it. Let the user confirm whether row one is a header, and default to treating it as data when you cannot tell. Guessing wrong either loses a record or labels columns with real values.

How do you make a wide CSV table readable on a phone?

Let it scroll sideways rather than shrinking every column: the CSS above already sets overflow-x on the wrapper. If it is still unusable, keep the two or three columns that identify the row and put the rest behind a details toggle, instead of compressing columns until words break mid-token.

What should a CSV preview do with a row that has too few columns?

Show it rather than dropping it, because a short row usually signals an unquoted comma or a broken export that only the uploader can fix. The parser above does not flag these itself; comparing each row's length against the header count and marking the row is a small addition.

Where to Go Next

The immediate next stop after a working preview is importing CSV into SQL, where the rows become real database records with validation and transaction safety. If you want to go deeper on the table markup and accessibility side, the HTML guide covers semantic structure and form patterns in more detail. For the styling side, CSS walks through layout, states, and the responsive constraints that keep tables readable on narrow screens.

The sibling poll widget guide covers the same browser-side project shape applied to form markup and accessible choices, and is worth reading alongside this one for the structural parallels.