Why splitting on commas is not enough
The obvious way to parse a CSV is to split each line on commas, and it works right up until the first real spreadsheet export — where a field like "Delhi, NCR" contains a comma of its own. RFC 4180 allows a field to be wrapped in quotes precisely so it can contain commas, newlines and quotes, and a parser that does not track quoting will shred those rows.
This one reads the input a character at a time and keeps track of whether it is inside a quoted field. While it is, commas and newlines are ordinary text; a doubled quote is an escaped quote. That is the whole difference between a converter that works on real exports and one that works on examples.
Type conversion, and when it hurts
CSV has no types — every value is text. Converting "42" to 42 and "true" to a boolean is usually what you want when the JSON is heading into code. It is emphatically not what you want for identifiers. A leading zero is meaningful in a PIN code, an employee number or a phone number, and a long account number cannot survive a round trip through a floating-point number without changing its last digits. Both cases are left as strings here, and the toggle turns the whole behaviour off when you would rather it did nothing.
Going the other way
Flattening JSON into CSV loses structure by definition — a CSV cell holds a value, not a nested object. Where a value is an object or an array it is written as JSON inside the cell, which is the least damaging option and survives a round trip back. If your data is deeply nested, flattening it into columns before converting will give you a far more useful spreadsheet.