Fix Ragged TSV Rows

rejoin wrapped records · pad · truncate · drop · reports the offending line numbers

"Row 4,812 has 7 fields, expected 6" — the error every TSV consumer eventually throws. The validator tells you where it happens; this page makes the file rectangular so it loads. Start with rejoin: a short row is usually not missing data but half a record, because a field contained a line break and the export wrote it out raw. Gluing the halves back together recovers the row rather than padding a hole that was never there — and the status line tells you how many rows look like that even when you have picked another action.

How to use

1. Paste or drop the file. The status line immediately reports the target width and which lines don't match it.
2. Check the width source. Header row is right when you trust row one; most common row width is right when the header itself is the broken row.
3. Pick an action. Pad-and-truncate produces a loadable file; drop bad rows produces a clean one at the cost of losing data.
4. Look at the named lines in the original before you accept the fix — see below for why.
5. Copy or download.

Why the file is ragged in the first place

A tab inside a field. The most common cause and the most dangerous, because padding hides it. A free-text field containing a tab splits into two columns, so that row has one extra field and everything after the tab is shifted one column right. Padding or truncating leaves a row full of correctly-counted but wrongly-placed data. If most bad rows have exactly one extra column, this is almost certainly what happened — fix the source instead, or run the file through escape tabs and newlines after re-exporting with quoting on.

A newline inside a field. One logical record becomes two physical lines — one too short, followed by another too short. If your bad line numbers come in adjacent pairs, that's the signature, and the status line counts the rows that fit it whichever action you have selected. Rejoin is the fix: the last field of the short row and the first field of the next are glued back into one cell, and the record comes back whole. Padding both halves instead gives you two broken records where you had one good one.

Genuinely optional trailing columns. Plenty of tools omit trailing empty fields, so a row ending in three empty values gets written short. Here padding is exactly right and completely safe — this is the case the tool is built for.

Concatenated files with different schemas. Two exports appended with cat, one with an extra column. The header row appears twice and widths differ in blocks. Merge TSV files handles this properly by unioning headers; padding does not.

What each action does

Rejoin rows split by a line break walks the file and, whenever a row is short and the following row is short enough to complete it, merges the two — repeatedly, because a field can contain more than one line break. The join character is yours to pick: a space reads best in a spreadsheet, \n as two literal characters keeps the break visible and reversible, and nothing at all is right when the break fell inside a word. Anything still ragged after the merge is padded or truncated and counted separately, so a residual count above zero means something other than a stray newline is wrong.

Pad short, truncate long forces every row to the target width — the file will load anywhere afterwards. Pad short only leaves over-long rows alone, so you keep the extra data and can inspect it. Truncate long only is for the reverse case. Drop bad rows removes anything that doesn't match the target; the count of dropped rows is your data-loss figure, and if it's large the target width is probably wrong.

Padding uses an empty string unless you supply something else. A literal marker like MISSING or \N is often better than an empty cell, because it survives a round trip through a spreadsheet and shows up in stats as a distinct value rather than as a null you might not notice.

FAQ

Privacy

100% client-side. No upload. See the privacy policy.