Convert comma-delimited data to tab-delimited (or back), handling quoted fields, embedded commas/tabs, and embedded quotes correctly — not just a find-and-replace on the delimiter character.
A naive comma-to-tab replace breaks the moment a field legitimately contains a comma inside quotes — "Smith, John" as a single quoted value would get split into two fields by a blind replace, silently corrupting the row. Correct conversion means actually parsing the structure — respecting quoted fields, doubled quotes as an escaped literal quote ("" → "), and embedded newlines inside a quoted field — then re-serializing with the new delimiter, quoting a field again only if it now contains the new delimiter, a quote character, or a newline.
Commas show up constantly in ordinary text — "Smith, John", "$1,200", "red, white, and blue" — so CSV fields need quoting often. Tabs almost never appear in typed or pasted text, so TSV output frequently doesn't need to quote fields at all, which is part of why some tools and spreadsheet paste operations default to TSV internally — it's often more readable as raw text, with visible tab characters instead of a wall of quotation marks.
This is an Excel behavior, not a conversion problem — Excel auto-detects numeric-looking columns and strips leading zeros or converts long digit strings to scientific notation when you open a plain CSV/TSV file directly. Import the file through Excel's Data → From Text/CSV wizard instead of double-clicking it, and set the affected column's type to Text during import to preserve it exactly as generated.
No — every row, including the first, is parsed and re-delimited the same way. If your file has a header row, it converts along with the rest; there's no special handling that assumes or requires one.
No. Parsing and re-serialization both happen with plain JavaScript running in your browser — no network request happens at any point, which you can confirm in your browser's dev tools Network tab.