CSV is text. Excel is a guesser.
An array of flat objects becomes rows. That is the happy path. Nested objects, arrays-of-arrays, and mixed keys across rows are where every converter pretends there is one true flatten and there is not. I stringify nested values or drop them depending on how the parser walks the first row; either way you should round-trip and look. Numbers become text in CSV and become numbers again if Excel feels like it. That last sentence is how SBIN0005943 becomes 5943 in a sheet and a NEFT bounces on Friday.
Paste stays in this tab. There is no upload API. There is also no magic BOM toggle in the UI, so Excel-on-Windows may mojibake UTF-8 names until you import as UTF-8 or prefix a BOM in a text editor. Semicolon locales (some EU Excels) will split on the wrong character if you expected commas. Delimiter is comma. If your locale uses comma as a decimal, you already live in hell; quote fields and test.
Worked example: a flat array
Paste [{"name":"Ada","score":10},{"name":"Raj","score":9}]. You should get a header row name,score and two data rows. Convert back. Diff against the original in the JSON diff if you are picky about types: 10 may come back as "10". For a gradebook that is annoying. For money it is an incident.
Worked example: nested address
{"name":"Ada","address":{"city":"Pune","pin":"411001"}} is not two clean columns without a rule. Some tools emit address.city. Some emit a JSON blob in one cell. Some drop address. If the cell contains curly braces, you did not flatten, you postponed the problem. Pull the fields you need in code, then convert a flat array. This page is a hop, not an ETL product.
Worked example: IFSC, PIN, phone, leading zeros
Export CSV. Open in Excel by double-click. Watch 011 (Delhi STD) or 000240 (an IFSC branch chunk) lose zeros. Workarounds people actually use: prefix a tab or apostrophe, or import via Data → From Text and set the column to Text, or wrap the value in ="SBIN0005943" if you must live in Excel formulas. Better: keep IFSC in JSON until the last mile, and use the IFSC finder on the code rather than trusting a sheet that has already guessed. PAN and Aadhaar do not belong in a CSV you email; flattening is not encryption.
What will bite you later
Huge files: memory-bound, not streaming. Newlines inside quoted fields. UTF-16 exports from old payroll software. A single object instead of an array (wrap it). Trailing commas in JSON. CSV that used tab separators. Types: CSV cannot store null vs empty string vs 0 without a convention you document. Pretty-print first in the JSON formatter if parse fails and you cannot see the missing brace.
Arrays as cell values ("tags":["a","b"]) become a string that Excel will not explode into columns unless you ask it to. Dates in JSON as ISO strings become Excel datetimes if they look like dates, or text if they do not. 2026-08-26 is a favorite for that coin-flip. Phone numbers with a leading plus get even weirder. If the sheet is a bank file, treat every identifier column as text at import time: IFSC, MICR, PIN, GSTIN, PAN. Flattening those into a CSV you then double-click is how Friday incidents start.
Questions
Is the data uploaded?
No. Paste stays in this tab. Still do not paste production dumps with PAN or tokens onto a shared screen.
How are nested objects handled?
Not uniquely. Flat arrays of objects are the happy path. Nested address blobs may stringify or drop. Flatten in code if you need address.city columns.
Why did Excel eat my IFSC zeros?
CSV is text; Excel guesses types. SBIN0005943 or 011 can lose leading zeros. Import the column as Text, or keep those codes out of double-click-open.
Comma or semicolon?
Comma. Some EU Excel locales expect semicolon. If columns collapse into one, check the separator, not the JSON.
Will types round-trip?
Not reliably. CSV is text. 10 may return as "10". Compare with the JSON diff if that matters.
UTF-8 in Excel?
Windows Excel often assumes a different code page on double-click. Import as UTF-8, or add a BOM in an editor if you must.