Transposing a Table Whose Rows Should Have Been Columns

What happens to the header row

Nothing special, and that is the point worth understanding before you use the result. The tool has no idea that your first row is a header. It reads a grid of cells, writes out the same grid with the axes swapped, and stops. So Name,Q1,Q2,Q3 over Alice,10,20,30 and Bob,5,6,7 becomes four rows: Name,Alice,Bob then Q1,10,5 then Q2,20,6 then Q3,30,7. Your column labels are now the first cell of every row, and your row labels — Alice and Bob — are now the header.

The first cell of the whole table, the one that said Name, ends up in the corner of the output as the label of a header row that no longer labels anything useful. That is normal for a transposed table and it is why most people rename it by hand afterwards — from Name to something like Metric or Period, depending on what is now running down the left. The important part is that whatever reads the file next still thinks the first row is a header, and that first row is now a list of your former row labels. If you feed the result into a CSV to JSON converter, your keys will be Name, Alice and Bob.

Ragged rows: it pads, and it never truncates

A real export is not always rectangular. A row can be short because a trailing field was empty and the writer stopped early; a row can be long because an unescaped delimiter split a field in two. Both happen, and a transposer has to decide what the height of the output is. This one uses the widest row: the number of output rows equals the number of cells in the longest input row, and every position that no input row filled becomes an empty string.

The demonstration is short. Take the header a,b,c above the two rows 1,2 and 3,4,5,6. The widest row has four cells, so the output has four rows: a,1,3 then b,2,4 then c,,5 then ,,6. Read that last row carefully. It carries the value 6, which is real data from the input, and its first cell is empty because the header only had three names. The tool is telling you something true and useful — there was a fourth field in one row and nothing named it — and it is telling you by leaving a nameless row at the bottom rather than by deleting the evidence. Truncating instead would have thrown away exactly the cell that proves your file has a quoting problem.

One side effect follows from that. Transposing a ragged table twice does not return the original: the first pass fills the holes, so the second pass rebuilds a rectangle. a,b,c over 1,2 and 3,4,5,6 comes back as a,b,c, over 1,2,, and 3,4,5,6 — same values, four columns everywhere, trailing empties where the original was short. On a rectangular table the double transpose is exact and returns the file you started with, byte for byte, provided the quoting was already minimal.

Types: the tool does nothing, and that is where the risk moves

There is no type conversion anywhere in this tool. It parses cells as text, moves them, and writes them back as text. 007 stays 007, 1.0 stays 1.0, true stays true, and a date stays whatever string it was. Nothing is rounded, nothing is reinterpreted, and a leading zero cannot be lost, because no number ever exists.

The risk is entirely downstream, and transposition creates it. Before the transpose, each column was homogeneous: a column of dates, a column of amounts, a column of region names. After it, each column is a mixture, because it holds one cell from every original column. Open the result in a spreadsheet and the type guessing runs column by column on data that no longer has a type per column. The label in the first cell is text and the rest is numbers, so a column of numbers gets read as text, or a stray cell that looks like a date gets converted into one. That is not the transposer's doing, but it is the transposer's consequence, and it is why the practical advice is to transpose in a text tool and open the result with every column set to text rather than letting a spreadsheet infer.

Where this comes up, and the one job it cannot do

Three situations account for most of it. A time series exported long, one row per period, when the chart you are building wants one column per period. A survey export where the questions are rows and the respondents are columns, or the reverse, depending on which tool wrote it. And a report where somebody built the pivot the wrong way round and shipped it, so the file that lands in your inbox has periods down the side and metrics across the top when everything else in your pipeline expects the opposite. In all three, the fix is a genuine transpose: the data is already the right shape, it is merely rotated.

There is a fourth situation that looks identical and is not, and this is the one that costs an afternoon. A long-format table has a key column that repeats: Date, Region, Sales, with two rows for January because there are two regions. Transposing that does not reshape it. Feed the tool Date,Region,Sales over 2026-01,North,120 and 2026-01,South,90 and 2026-02,North,140, and the output is three rows: Date,2026-01,2026-01,2026-02 then Region,North,South,North then Sales,120,90,140. The first row now has a duplicate header, and the table is still long — one entry per observation, just written sideways. What you wanted was a pivot: group by date, spread the regions across columns, and put the sales in the cells. That is an aggregation, not a rotation, and it needs a tool that knows which column is the key, which is the label and which is the value.

Three quiet behaviours worth knowing

A blank line inside your input becomes an empty column in the output. It is not a bug and it follows directly from the definition: a blank line is a row containing one empty cell, so after the rotation it is a column containing one empty cell plus padding. Give the tool a,b then 1,2 then a blank line then 3,4, and you get a,1,,3 over b,2,,4 — the third column is the blank line. Since people paste data with blank lines separating blocks more often than they think, this is the most common surprise the tool produces. Strip empty lines before transposing if you did not mean them.

The delimiter comes out as it went in. It is detected on the first record and reused for the output, so a semicolon file transposes to a semicolon file and a tab file to a tab file. There is no option to change it on the way through — if you want a different one, run the delimiter converter afterwards. The corollary is that a wrong detection ruins the result rather than degrading it: force the delimiter to a comma on a file that really uses semicolons and every line becomes a single cell, so the whole table transposes into one row.

Quoting is rebuilt, not carried over. Every cell is re-examined on the way out and quoted only if it now contains the delimiter, a quote or a line break. A cell holding y,z was quoted in the input and is quoted again in the output; a cell that was quoted for no reason comes back bare. Cells with embedded newlines survive intact, still quoted, still spanning two physical lines in the file. This means the output is a valid CSV even when the input was quoted more heavily than it needed to be — and it also means a byte-for-byte comparison of a double transpose will differ if the original had superfluous quotes.

Frequently asked questions

Does the first row get treated as a header?

No, and there is no option to say it is. The tool reads a grid and rotates it; every row is a row. That is the behaviour you want, because a transposer that treated the first row specially would have to decide what to do with it — keep it on top, which would not be a transpose, or move it and pretend it is still a header, which would be a lie. The consequence is that after transposing you will usually want to rename the very first cell by hand, because it now labels a header row made of your former row labels rather than a column of anything.

How big a file can I transpose?

The drop area accepts files up to 2 MB, and everything runs in your browser rather than on a server, so nothing is uploaded. The real limit for a transpose is not the file size but the shape: transposing turns rows into columns, so a file with 50,000 rows becomes a file with 50,000 columns. That is valid CSV and the tool will produce it, but very few programs open it comfortably — spreadsheet column limits are typically in the tens of thousands, and a text editor will give you one line several megabytes wide. If your table is tall rather than wide, ask whether you want a transpose at all, or whether what you actually need is a pivot that groups the rows down to a handful of columns.

Why does my transposed file have a column full of nothing?

Almost certainly because the input had a blank line where that column now is. A blank line parses as a row containing one empty cell, and after the rotation that row is a column. Count from the left: the position of the empty column matches the position of the blank line counting from the top. The same thing happens with a row of nothing but delimiters, such as ,,, which is four empty cells rather than a blank line but produces the same visual result. Remove the empty lines from your input first — a trailing newline at the very end of the file is handled and does not cause this, but a blank line in the middle does.

Can I transpose only part of the file?

Not in one step — the transposer takes the whole input. The practical route is to cut first and transpose second. Paste only the block you want, or pull the columns you care about with a column extractor and transpose the result, which is often what you actually wanted anyway: a wide table transposed in full is unreadable, while four selected columns transposed into four rows is a summary you can put in a message. If the file has several blocks separated by blank lines, remember that those blank lines become empty columns, so split the blocks into separate inputs rather than transposing all of them together.

I need one column per month from a table that has one row per month. Is that a transpose?

It depends on one thing: whether the month appears more than once. If each month has exactly one row, then yes — the table is already the right shape and rotating it gives you what you want. If a month appears several times because there is a second dimension in the table, such as a region or a product, then no. Rotating that gives you repeated month labels across the top and leaves you exactly as far from the answer as you were. What you need there is a pivot: choose the key that becomes the rows, the label whose distinct values become the columns, and the value that lands in the cells, and decide what happens when two source rows land in the same cell — sum them, average them, or refuse. A transposer has none of those three inputs and cannot ask for them.