Why did my postcodes lose their leading zeros?

The importer may have treated the identifier as a number. Import the original CSV with that column set to Text, then save as XLSX if needed. Quoting values or changing the file format alone does not guarantee that leading zeros survive.

Why is my CSV full of strange characters?

It is an encoding mismatch — most often a UTF-8 file opened as a legacy Windows codepage. There is nothing in a CSV that declares its encoding, so the reader has to guess. Re-import specifying UTF-8, or convert to XLSX, which is UTF-8 by definition.

Can deeply nested JSON convert to a spreadsheet?

It will convert, but a deeply nested tree has no meaningful table form — the relationships between levels cannot survive flattening. An array of flat records converts cleanly. For a configuration tree, convert to a readable document instead and keep the original for anything that needs to use the data.

My conversion failed with a parse error. Why?

The source file is not valid — a trailing comma in JSON, an unclosed XML tag, inconsistent YAML indentation. The job stops rather than producing a document that looks complete but is missing records. Validate the file with a linter for its format; the error names the line.

Data Converter

Convert CSV, JSON, XML, and YAML. Open your data in Excel without losing leading zeros or breaking Arabic text, or export it as a readable PDF or Word table.

Popular conversions

CSV to Excel Converter JSON to PDF Converter JSON to Word Converter JSON to CSV Converter XML to PDF Converter XML to CSV Converter CSV to PDF Converter

All supported formats

CSVJSON XML YAML TOML

A tree, a grid, and a page

JSON, XML, YAML, and TOML all describe trees: values inside objects inside arrays, nested as deeply as you like. CSV describes a grid. A PDF describes a page. There is no mechanical translation between a tree and a grid, so every conversion out of this family involves a decision about how to flatten.

An array of flat records converts to a table perfectly — and that is the shape most people actually have, which is why these conversions work as often as they do. The trouble starts when values are themselves structures: if a record contains an address object, does that become one column or four? There are defensible answers and no universally correct one.

Choosing a target

You want	Convert to
To analyse the data in a spreadsheet	XLSX — it keeps cell types, unlike CSV
To hand something readable to a colleague	PDF
To put the data into a report you are writing	DOCX, where it lands as an editable table
To scan it quickly yourself	TXT
To move it between systems	Another structured format — JSON to YAML, XML to JSON

The CSV traps worth knowing

CSV looks like the simplest format there is and it quietly corrupts data more often than any other. It has no way to declare a type, an encoding, or a delimiter, so every program that opens one has to guess, and guesses differ.

The classic failure is leading zeros: a column of postcodes or account numbers like 01067 is read as a number and displayed as 1067, permanently, once the sheet is saved. The second is encoding — a UTF-8 file read as a legacy codepage turns accented and Arabic text into line noise. The third is the delimiter, which is a semicolon in locales where the comma is the decimal separator.

XLSX stores explicit cell types and does not use a CSV delimiter. It preserves the values as interpreted during import, so check encoding, identifiers, dates, and column boundaries first. Changing the output format does not repair a misread source.

Bad input fails loudly

A JSON file with a trailing comma, an XML file with an unclosed tag, or a YAML file with inconsistent indentation stops the conversion with a parse error rather than producing a half-converted document.

This is the right behaviour. A converter that silently skipped what it could not parse would hand you something that looks complete and is missing records — far worse than an error, because you would not find out until it mattered.

Related converters

Document Converter Browse all formats →

Frequently asked questions

Why did my postcodes lose their leading zeros?: The importer may have treated the identifier as a number. Import the original CSV with that column set to Text, then save as XLSX if needed. Quoting values or changing the file format alone does not guarantee that leading zeros survive.
Why is my CSV full of strange characters?: It is an encoding mismatch — most often a UTF-8 file opened as a legacy Windows codepage. There is nothing in a CSV that declares its encoding, so the reader has to guess. Re-import specifying UTF-8, or convert to XLSX, which is UTF-8 by definition.
Can deeply nested JSON convert to a spreadsheet?: It will convert, but a deeply nested tree has no meaningful table form — the relationships between levels cannot survive flattening. An array of flat records converts cleanly. For a configuration tree, convert to a readable document instead and keep the original for anything that needs to use the data.
My conversion failed with a parse error. Why?: The source file is not valid — a trailing comma in JSON, an unclosed XML tag, inconsistent YAML indentation. The job stops rather than producing a document that looks complete but is missing records. Validate the file with a linter for its format; the error names the line.
Is the Data Converter free?: Yes, every conversion is completely free with no account and no watermark.
Do I need to install anything?: No. Use the tool from your browser; files are uploaded to our servers for processing.
Are my files safe?: Files are auto-deleted after 2 hours and are never shared.