Escape Tabs and Newlines in TSV
The TSV specification has no quoting: a field may not contain a tab, a carriage return, or a line feed, and there is no escape hatch. In practice tools cheat by borrowing CSV's quotes, which works until it meets a strict reader that treats every tab as a delimiter regardless of quotes. This page resolves the conflict the other way — it parses your quoted input, replaces the offending characters with the two-character sequences \t, \n, and \r, and writes output with no quotes at all. Reverse it with unescape.
How to use
- Paste or drop a TSV whose fields contain tabs or newlines — normally these arrive quoted, from a spreadsheet export or a CSV conversion.
- Leave the backslash option on unless you know your data contains no backslashes and you want the output to stay literal.
- Copy or download. The status line tells you how many fields were rewritten.
Why escape rather than quote
Quoting is the CSV answer and it requires the reader to implement a small state machine. Many TSV readers don't: cut -f2, awk -F'\t', LOAD DATA INFILE with default settings, R's read.delim with quote="", and most bioinformatics tooling all split on every tab they see. Feed them a quoted field containing a tab and the row silently gains a column — the exact failure that fix ragged rows exists to clean up after.
Backslash escapes sidestep the state machine entirely. Every line has exactly the same number of tabs, so a naive splitter is correct, and the escapes are visible in a terminal instead of being invisible whitespace. It is also what PostgreSQL's own COPY … WITH (FORMAT text) does by default, and what mysql --batch emits: \t, \n, \\, and \N for NULL. If you're producing a file for either of those loaders, this is the format they expect.
Why the backslash option matters
Without it, escaping is not reversible. Consider a field whose literal text is C:\temp followed by a real tab. Escape only the tab and you get C:\temp\t… — now indistinguishable from a field containing C: then a tab then emp. Escaping existing backslashes first turns it into C:\\temp\t…, which unescapes back to exactly what you started with.
Turn the option off only when the data has no backslashes at all, or when a consumer specifically wants single-backslash escapes and you accept the ambiguity. The unescape tool reverses both conventions — it just can't tell you which one produced the file.
FAQ
My input has no quoting — will this still help?
If nothing is quoted, then a tab inside a field is already indistinguishable from a delimiter and the damage is done: the parser sees an extra column, not a field with a tab in it. There's nothing to escape. Re-export the source with quoting enabled and come back, or if the shift is consistent, repair the columns with fix ragged rows and accept the loss.
Does it escape quote characters too?
No — a double quote is a perfectly legal character inside a strict TSV field, since there's no quoting for it to interfere with. Input quotes are consumed as syntax on parse, so "say ""hi""" comes out as say "hi" with the quotes intact as data.
What about NULL vs empty string?
TSV cannot distinguish them, and this tool doesn't try — both are empty. Postgres and MySQL use \N as the NULL sentinel in their text formats; if you need that, add it with fill empty cells after escaping.
Is there a way to check the result is strict?
Every line will have the same number of tabs and no quotes. The validator confirms the column counts, and searching the output for a " character confirms the quoting is gone.
Privacy
100% client-side. No upload. See the privacy policy.