Unescape Tabs and Newlines in TSV
A file full of visible \t and \n sequences is what you get out of psql's text format, mysql --batch, and anything that follows the strict no-quoting reading of TSV. That's correct as a wire format and wrong as data — nobody wants a description field that literally reads line one\nline two. This turns the escape sequences back into the characters they stand for, and quotes any field that ends up containing a tab or newline so the file remains parseable. The forward direction is escape tabs and newlines.
How to use
- Paste or drop the escaped file. Nothing else needs configuring for the common case.
- Keep quote fields ticked. Unticking it produces a file with real tabs inside fields and no quoting — which is, by definition, unparseable. The status line will warn you.
- Copy or download.
What gets converted
\t becomes a tab, \n a line feed, \r a carriage return, and \\ a single backslash. Any other backslash pair — \d, \N, \. — is left exactly as it is, on the grounds that guessing at unknown escapes does more harm than good. That deliberately leaves Postgres's \N NULL marker intact so you can decide what to do with it yourself.
The conversion happens in a single pass over each field, which matters: \\t becomes a backslash followed by the letter t, not a tab, because the escaped backslash is consumed first. A two-pass find-and-replace would get this wrong, which is why a plain find and replace is not a substitute for this page when your data contains backslashes.
The quoting question
Once a field genuinely contains a tab, the file needs some way to say "this tab isn't a delimiter". The only widely-understood convention is CSV-style quoting, so that's what the tool writes: affected fields get wrapped in double quotes, and any quote already inside them is doubled. Files like that are read correctly by Python's csv module, R's read.delim, pandas, Excel, and anything else with a proper parser.
If your consumer is a strict tab-splitter, unescaping is the wrong operation for it entirely — keep the escaped form and let the consumer see \t. The realistic reason to unescape is that you're moving the data into a spreadsheet, a JSON document, or a database column where the real characters belong. In the JSON case you can skip the quoting worry altogether: unescape here, then TSV → JSON, and JSON does its own escaping.
FAQ
Why did my row count change?
It shouldn't — the newlines created are inside quoted fields, so a parser still sees the same number of records. What changes is the number of lines in the file, which is a different thing. If a tool downstream reports more rows than expected, it's counting lines rather than parsing records.
Can I unescape only one column?
Not here — the whole file is processed. For a single column, find and replace in a column lets you target it, with the caveat about backslash ordering above: replace \\ last, or not at all.
What about \u escapes?
Left alone. Unicode escape sequences are a JSON and Java convention rather than a TSV one, and decoding them would risk mangling legitimate text. Convert to JSON and back if you need them resolved.
Privacy
100% client-side. No upload. See the privacy policy.