About

Misaligned columns in plain-text data cause parsing failures, misread reports, and broken documentation. This converter transforms raw CSV input into precisely formatted ASCII tables using character-level column-width analysis. Each column width w_j is computed as the maximum string length across all n rows for column j, guaranteeing uniform alignment regardless of data variance. The parser implements a finite-state machine compliant with RFC 4180, correctly handling quoted fields containing commas, newlines, and escaped double-quotes (""). Seven output styles are supported: MySQL grid, PostgreSQL, Markdown, Unicode box-drawing (U+2500 block), reStructuredText, compact, and simple.

The tool approximates output width as W = ∑ w_j + 3k + 1, where k is the column count and 3 accounts for padding and separator characters per column. Limitations: tab-separated values require selecting the tab delimiter. Fields exceeding 500 characters are truncated to prevent terminal overflow. Pro tip: Markdown style output pastes directly into GitHub README files and Jira tickets without modification.

Formulas

Column width for each column j is determined by scanning all rows:

w_j = max({ len(cell_i,j) | i ∈ 1..n })

Total table width including borders and padding:

W = k∑j=1 (w_j + 2) + k + 1

Where w_j = computed width of column j, k = total number of columns, n = total number of rows, 2 = left and right padding per cell, k + 1 = number of vertical border characters. The CSV parser operates as a deterministic finite automaton with 4 states:

S = { FIELD_START, UNQUOTED, QUOTED, QUOTE_ESCAPE }

Transitions: at FIELD_START, a " character transitions to QUOTED; any other character transitions to UNQUOTED. Inside QUOTED, a " transitions to QUOTE_ESCAPE, where a second " emits a literal quote and returns to QUOTED, while any other character finalizes the field.

Reference Data

Style	Corner	Horizontal	Vertical	Cross	Best Use
MySQL	+	-	\|	+	Database CLI output
PostgreSQL	+	-	\|	+	psql-style reports
Markdown	\|	-	\|	\|	GitHub, Jira, docs
Unicode	┌┐└┘	─	│	┼	Terminal dashboards
reStructuredText	+	= / -	\|	+	Sphinx documentation
Simple	(none)	-	(space)	(none)	Quick readable output
Compact	(none)	(none)	(space)	(none)	Minimal space usage
RFC 4180 CSV Parsing Rules
Rule 1	Records delimited by CRLF, LF, or CR
Rule 2	Optional header row (first row treated as header by default)
Rule 3	Fields separated by comma (configurable delimiter)
Rule 4	Fields containing delimiters, quotes, or newlines must be enclosed in double quotes
Rule 5	Double quotes inside quoted fields escaped as ""
Common Delimiter Characters
Comma	,		Standard CSV (RFC 4180)
Tab	\t		TSV files, spreadsheet exports
Semicolon	;		European locale CSV
Pipe	\|		Database dumps, log files
Colon	:		/etc/passwd, config files
Space	(whitespace)		Fixed-width-like data

Frequently Asked Questions

The parser follows RFC 4180 rules. Any field containing the delimiter character, a newline, or a double-quote must be enclosed in double quotes in the source CSV. The finite-state machine enters the QUOTED state upon encountering an opening quote, and only exits when it finds a closing quote followed by a delimiter, newline, or end-of-input. This means commas and newlines inside quoted fields are preserved as literal cell content rather than being interpreted as structural separators.

Both use the same border characters (+, -, |). The difference is structural: MySQL style draws a top border, a header separator, and a bottom border (3 horizontal rules). PostgreSQL style omits the top and bottom borders, drawing only a single separator line under the header row using - characters with + at column intersections. PostgreSQL output is more compact and matches the default psql terminal rendering.

Unicode box-drawing characters (U+2500 to U+257F) require a monospaced font that includes these glyphs. Common culprits: Windows Notepad with raster fonts, or terminals using bitmap fonts. Switch to a font that supports the Unicode Box Drawing block: Consolas, Fira Code, JetBrains Mono, or DejaVu Sans Mono. Additionally, ensure your terminal encoding is set to UTF-8, not ASCII or Latin-1.

Select ; (semicolon) from the delimiter dropdown. Many European locales use semicolons because the comma serves as the decimal separator in numbers (e.g., 3,14 instead of 3.14). The parser treats the selected delimiter identically to how it would treat a comma in standard CSV: it triggers field separation unless the delimiter appears inside a quoted field.

The converter normalizes all rows to the maximum column count found in the dataset. Rows with fewer fields are padded with empty strings on the right. This ensures the ASCII table renders with consistent column widths. The column width calculation w_j still applies correctly because empty strings have length 0 and do not affect the maximum.

The tool enforces a 10 MB file size limit to prevent browser memory issues. For files above 50 KB, parsing is chunked asynchronously with a progress indicator. Individual cell values exceeding 500 characters are truncated with an ellipsis to prevent excessively wide tables. There is no hard row limit, but rendering tables beyond approximately 10,000 rows may cause sluggish scrolling depending on the browser.