SheetCompareCSV to Markdown Table Converter
Turn a CSV into a GitHub-flavored Markdown pipe table you can paste into a README, doc, or PR description.
Drop your file here
Accepts CSV · Runs in your browser. Your file never leaves your device.
Markdown's table syntax is the most common way to ship a small dataset inside a README, a GitHub issue, a PR description, a Notion page, or any technical doc that renders Markdown. Writing the pipes and dashes by hand for anything beyond a few rows is tedious and error-prone — one missing pipe and the whole table breaks.
This tool converts your CSV directly to GitHub-Flavored Markdown (GFM) pipe-table syntax. The header row, separator row, and data rows are all generated for you. Special characters inside cells (literal pipes, embedded newlines) are escaped so the output renders cleanly. Conversion runs entirely in your browser.
Three steps, no signup
- 1
Drop your CSV
Drag a .csv file into the box above, or click to pick one. The first row is treated as the table header.
- 2
We render the pipe table
Headers go in the first line wrapped in pipes, followed by a separator line of `|---|`, followed by one pipe-wrapped line per data row. Pipes inside cells are escaped, newlines become <br>.
- 3
Download the .md
A plain Markdown file with your table is ready instantly. Open in any Markdown editor, paste into a README, or drop into a GitHub issue.
Frequently asked questions
- What does the output Markdown look like?
- Standard GFM pipe-table syntax. A CSV with headers `name,age` and rows `Alice,30` and `Bob,25` produces: | name | age | | --- | --- | | Alice | 30 | | Bob | 25 | The second line of dashes is the GFM separator that distinguishes the header from the body. Every renderer that supports tables (GitHub, GitLab, VS Code preview, Notion, Obsidian, MkDocs, Docusaurus) understands this format.
- What happens with very long rows?
- The Markdown source line stays long (one line per row, no wrapping), but most Markdown renderers will visually wrap or scroll the table when it's wider than the container. There's no ASCII-art column padding — the source intentionally stays compact rather than aligning by column width. If you want pretty source alignment, pipe the output through a Markdown formatter like `prettier --parser markdown` afterward.
- What if a cell contains a literal pipe character?
- Escaped as `\|` so it renders as a literal `|` inside the cell instead of being parsed as a column separator. So a cell containing `a|b` becomes `a\|b` in the source and `a|b` when rendered.
- What about cells with newlines or multi-line content?
- Newlines inside cells are replaced with `<br>` so the row stays on a single Markdown source line — pipe tables can't span multiple lines. Most renderers (GitHub included) honor `<br>` as a line break inside the cell when displayed. If you need true multi-paragraph cell content, Markdown tables aren't the right format; use a definition list or HTML `<table>` instead.
- Is this CommonMark or GitHub-Flavored Markdown?
- GitHub-Flavored Markdown (GFM). Pipe tables aren't part of the CommonMark spec — they're a GFM extension that almost every modern Markdown renderer also supports (GitHub, GitLab, Bitbucket, Obsidian, Notion, MkDocs, Docusaurus, Hugo, Jekyll with `kramdown`). Pure CommonMark renderers (rare these days) won't render the table, but the source still reads fine as a code-style block.
- When should I use a Markdown table vs. a screenshot or a code block?
- Markdown tables when you want the data to be searchable, copy-pasteable, accessible, and small (under ~30 rows by ~10 columns). Screenshots when the formatting matters more than the content (charts, conditional coloring, anything Excel-rendered). Fenced code blocks for tabular data that's intentionally meant to look like raw CSV/TSV — useful for command-line examples or schema definitions.
- Will the column widths be aligned in the source?
- No — the output uses single-space padding around each cell with no width-based alignment. This keeps the source compact and the converter fast. The rendered table will still look correctly aligned in the browser; only the raw `.md` source is ragged. If you want aligned source, run the output through `prettier --parser markdown` or a similar formatter.