Fix Ragged TSV Rows

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. Pick a target width, decide whether short rows get padded and long rows get cut, and the status line names the first offending lines so you can go and look at what actually went wrong before you paper over it.

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 one too short. If your bad line numbers come in adjacent pairs, that's the signature. Padding both halves 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

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.