tsvkit.org
TSV Toolkit
Sample data Say hi →

Fixed-Width Text to TSV

auto-detects boundaries · or give explicit widths · runs in your browser

Column-aligned text is the output of everything that predates CSV: mainframe extracts, COBOL record layouts, ps, df, netstat, printed reports pasted out of a PDF. It looks tabular but there is no delimiter — the columns are held together by padding. This finds the boundaries and turns them into real tabs, which is the point at which a spreadsheet or a database will finally accept the file.

columns
Drop a .txt file here, or
ready

How to use

  1. Paste the text or drop the file. Keep the header line if there is one — it becomes the TSV header.
  2. Leave Widths blank to auto-detect. The status line tells you how many columns were found and at which character offsets.
  3. If auto-detect is wrong, type the widths in characters, comma-separated: 10,8,12,20. The last column runs to the end of the line, so its width doesn't matter.
  4. Check the output in a grid with the TSV viewer before you use it — misaligned boundaries are obvious there and invisible in raw text.

How auto-detection works, and when it fails

A character position is a column boundary if every line has a space there. The tool finds each run of such positions and cuts at the first non-space column after it. That's a simple rule and it is right most of the time, because padding is exactly what fixed-width formatting produces.

It fails in two specific ways. A value that fills its field completely removes the gap for that line, and two columns get merged for every row. A value containing a space — a person's name, a description — creates a gap that isn't a boundary only if some other row happens to have a space in the same position, which is why one long line can rescue the detection and one short file can ruin it. In both cases, count the characters on a representative line and enter explicit widths. That is always exact, and it is what a real record layout gives you anyway.

The two cleanup options

Trim each field strips the padding spaces from every value, which is almost always what you want — the padding is formatting, not data. Uncheck it if the field width is semantically meaningful, for example a zero-padded code that used spaces instead of zeroes.

Drop rule lines removes lines made entirely of -, =, +, |, _, * or spaces — the separator rows printed under a header in almost every report. They would otherwise become a row of dashes in your data. Tabs in the input are expanded to four spaces before anything else happens, since a stray tab inside a supposedly fixed-width file would otherwise wreck the alignment.

FAQ

What about the reverse — TSV back to aligned columns?

That's aligned text columns, which pads each field to the width of its longest value. The round trip is lossless as long as no value has leading or trailing spaces that matter.

My record layout is in bytes, not characters. Does that matter?

Only if the file is not ASCII. Widths here are counted in characters as the browser sees them, so a UTF-8 file with accented or CJK characters will have byte offsets that don't match character offsets. Legacy fixed-width files are usually single-byte encodings — convert with convert encoding first if yours is EBCDIC or Latin-1, and the offsets will then line up.

Can it handle a file with no header?

Yes — every line is treated the same. The first line simply becomes the first TSV row, which most other tools here will then read as a header. Add a proper one with header tools.

The output has an empty first column. Why?

Every line is indented, so position 0 is a boundary. Either strip the indent before pasting, or give explicit widths starting with the indent as its own throwaway column and delete it afterwards with delete columns.

Privacy

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