TSV to ASCII Table
A bordered text table for places that render no markup: a terminal, a code comment, a commit message, a plain-text email, an issue description in a tracker that mangles Markdown tables. Columns are padded to a common width so everything lines up in any monospace font, and numeric columns are right-aligned so the digits align too. For an aligned table without borders, TSV → text columns is the leaner option.
How to use
- Paste or drop the TSV. Row one is treated as the header and gets a rule under it.
- Pick a style. Unicode looks best; ASCII is the safe choice for anywhere the encoding is uncertain.
- Set a max cell width if one long column is stretching the table — longer values are truncated with an ellipsis.
- Copy into a monospace context. In a proportional font the alignment collapses; wrap it in a code block if the destination supports one.
Choosing a style
Unicode box is the default and renders correctly in every modern terminal and editor. ASCII uses only -, |, and +, which survives any encoding, any legacy console, and any system that might re-encode your text — the right choice for a log file or a system that predates UTF-8. Rounded is Unicode with soft corners, common in modern CLI output. Double lines are heavier and mostly nostalgic; they were the DOS-era convention.
Zero cell padding produces the most compact table, which is worth using when a table is close to the width limit of wherever it's going — 80 columns for a commit message body, 72 for plain-text email.
The width caveat
Column widths are computed by counting characters, which is exactly right for Latin text and digits but not for everything. CJK characters occupy two terminal cells each while counting as one character, so a table containing Chinese, Japanese, or Korean text will look slightly narrow in those columns. Emoji and combining accents have the same problem. There's no way to fix this without knowing the rendering font, and every tool that does this in a terminal has the same limitation.
Tabs and newlines inside cells are replaced with spaces, since either would destroy the alignment. If your cells contain real line breaks, the table will be readable but those cells will be long — a max cell width is the practical answer.
FAQ
Can it wrap long text instead of truncating?
No — wrapping would mean multi-line rows, which needs a different drawing algorithm and makes copy-paste back into data much harder. Truncation keeps one row per record.
Will this paste into GitHub or Slack correctly?
Only inside a code block — triple backticks in both. Outside one, the proportional font destroys the alignment. If the destination understands Markdown tables, TSV → Markdown gives a better result there.
Is there a row limit?
None enforced, but a 10,000-row box table isn't something anyone reads. Slice rows down to the part you want to show first.
Can I convert an ASCII table back to TSV?
Not with a tool here — the borders make it ambiguous where a padded cell ends and whether a space belonged to the data. Keep the TSV as the source of truth and regenerate the display version.
Privacy
100% client-side. No upload. See the privacy policy.