Data Format Converter: Moving Text Between 99 Formats Without Silent Damage

By xaxxon · Seattle, WA

A format conversion looks like a button. Paste text, pick a target, get output. Under the button sits a harder question: does the output still mean the same thing as the input? CSV, JSON, YAML, XML and SQL each store data in a different shape, so every conversion is a translation between models, not a rename of a file extension. This article walks through what the Data Format Converter does, which conversions keep every value, which ones quietly drop structure, and what to check on the result before you feed it to a database, an API or a spreadsheet.

What a Data Format Converter Actually Does

Inside the browser, the tool runs a two stage pipeline. The source format is parsed into a shared intermediate model, then the target format is written from that model. For tabular formats the model is a list of rows with named columns. For tree formats it is a document tree. For line based formats it is a list of records.

That design explains both what works and what fails. A conversion can only move what the intermediate model can hold. If you go from CSV to JSON, the model holds every cell, so nothing is lost. If you go from JSON with nested objects to CSV, the model holds rows, and the nesting has to be flattened or dropped. The tool reports a parse error when the source text cannot supply the fields the target needs, instead of writing a half empty file.

The interface is one screen. Two selects on top, input on the left, output on the right. The From list groups all 99 formats into 15 families, so you scroll to JSON or Configs instead of hunting through an alphabetical wall of extensions. Every entry in the registry has a working codec, which is why the badge reads 99 of 99 ready. Load Sample drops in an example of the selected source format, Swap moves the result back into the input and flips the two selects, and Copy or Download take the output with the correct extension and MIME type.

Everything runs locally. The text never leaves the page, no upload happens, and there is no account, quota or key. That matters when the payload is a customer export or an internal config, and it also means the browser's memory is the real limit on file size.

The Loss Matrix: What Survives Each Conversion

Moving data toward a richer model is safe. CSV to JSON gains types and structure without losing values. JSON to YAML is close to lossless because YAML can represent the same trees. Moving toward a simpler model costs features. JSON to CSV loses nesting, XML to JSON loses attributes and namespaces, and TOML to CSV keeps only what fits in a flat row.

Three rows in that table deserve a closer look. XML attributes have no standard JSON form: some libraries emit @id, some _id, some wrap them in a _attributes object, and some drop them entirely. Two converters applied to the same document can produce two different JSON files, both valid. YAML carries comments, anchors and merge keys that JSON cannot express, so a config file converted to JSON and back comes out valid but annotated in a different way. And every table conversion turns numbers into text or text into numbers depending on inference rules, which is where leading zeros disappear.

A round trip is not a proof of safety either. JSON to YAML to JSON usually returns the original. CSV to JSON to CSV returns the original for flat data. XML to JSON to XML does not, because element order, attributes, namespaces and processing instructions have nowhere to live in JSON. Test the round trip on your own sample before you trust it on a full export.

CSV and JSON: The Two Poles

CSV looks simple until a field contains a comma. The rules live in RFC 4180: quote any field that holds a delimiter, a quote or a newline, and double the internal quotes. A row like 1,Jane Doe,123 Main St, Apt 4B, Portland silently becomes five columns instead of three. The fix is boring and it is the whole game: quote anything questionable, keep the dialect consistent, declare the encoding.

Encoding is the second trap. A CSV is bytes, and bytes need a declared encoding. UTF-8 without a BOM opened in Excel on Windows shows café as café. UTF-8 with a BOM sent to a strict parser turns the first header into \uFEFFid, and your join breaks. For a file a human will open, UTF-8 with a BOM is the practical default. For a machine pipeline, UTF-8 without one. The converter reads pasted text as UTF-8 and preserves whatever characters you paste, so the encoding decision stays on the side that produced the file.

Then there is type inference, which is where CSV to JSON earns its bad reputation. A cell holding 30 can become the number 30 or the string "30". Both are defensible, and both break something: numbers break on a column that also contains N/A, strings break on a downstream schema that expects integers. Leading zeros are worse. 01234 becomes 1234, 0123456789 becomes 1.23457E+08 in a spreadsheet, and 3/4 in a product code becomes 4-Mar. Excel's gene name bug is famous enough that researchers renamed 27 genes to stop their symbols being read as dates.

JSON has the opposite problem: it is precise about types and vague about size. Long numeric IDs lose precision when a parser uses IEEE 754 doubles, so an order number like 9007199254740993 comes back rounded. Keep identifiers as strings on the JSON side if they matter. For big exports, JSON Lines is the format to pick: one object per line means a converter can stream row by row instead of holding the whole array in memory.

XML, YAML and Config Files: Where Structure Hides

XML is a document format, not a data format, and the difference shows the moment you convert it. An element can carry attributes, text, children, namespaces and mixed content. JSON has keys and values. Any mapping between them is a convention, and conventions differ between libraries. Decide the rule before converting, then check the output with the parser that will consume it.

YAML is close enough to JSON that people treat them as synonyms, which causes quiet bugs. YAML 1.1 reads yes, no, on and off as booleans; YAML 1.2 does not. That is the Norway problem: a country code NO turns into false in an older parser. Dates, timestamps and unquoted strings like 1.0 behave differently depending on the parser and version too. Convert YAML to JSON with the version your application actually uses, and quote anything that looks like a scalar but must stay text.

TOML adds a hard limit that surprises people: it has no null. An empty value either disappears, becomes an empty string, or forces you to invent a sentinel. INI and Java properties are flatter still: sections, keys, values, and no type system at all. Properties files also treat \ as an escape character and split long values with trailing backslashes, so a Windows path pasted into a .properties file can swallow the next line.

Config files that look like code have their own grammar. An nginx config is blocks and directives, a systemd unit is sections and assignments, an SSH config is Host blocks with keywords, a crontab is five fields and a command. Converting them to YAML or JSON keeps the values but loses indentation meaning, and indentation is the structure. This is a case where a converter helps you inspect and compare, not a case where the output should replace the original file.

SQL Dumps, Logs and Subtitles: Formats With Rules

A SQL dump is not one format. INSERT statements, a MySQL dump with CREATE TABLE blocks, a PostgreSQL COPY block and a SQLite .dump all describe table rows in different syntax, and each treats nulls, quoting and escapes differently. In COPY text format a tab separates columns and a newline ends the row, so a literal newline inside a value must be escaped or it splits the record. Convert a dump to CSV and you get the rows, but constraints, indexes and defaults stay behind, because a flat table cannot carry them.

Log formats are positional. The Common Log Format has nine fields in a fixed order, the W3C extended format declares its fields in a header line, logfmt is key equals value pairs, and LTSV uses colon separated labels. Converting a log to JSON works well because the fields are named or ordered, and the usual failure is a request string containing a quote or a space that was not escaped by whoever wrote the log.

Subtitles look trivial and are not. SubRip writes 00:00:01,000 --> 00:00:03,000 with a comma before milliseconds. WebVTT writes 00:00:01.000 --> 00:00:03.000 with a dot and starts with the WEBVTT header. ASS carries styling and layer numbers that plain text formats cannot hold. Convert SRT to VTT and the timings survive; convert VTT to ASS and you get text on screen without the styling the original had.

Encoding formats are the cleanest conversions in the tool. Base64, Base32, Base16 and Base85 move bytes into printable text and back. The trap is not the conversion, it is the payload size and the line wrapping: some tools expect 76 character lines, some expect none, and a PEM block has its own header and footer that must stay intact.

A Pre Flight Check Before You Paste a Dataset

The cheapest way to avoid a bad conversion is a small sample that carries the edge cases. Take ten rows, not ten thousand: an empty cell, a value with a comma, a value with a quote, a value with a newline, a non ASCII name, a date, a boolean, a long number and a leading zero identifier. Convert that sample first. If the sample survives, the full dataset probably will too, and if it does not, you find out in seconds instead of after an import.

Then check the result against the destination, not against your hope. Count records on both sides: 1,000 source rows turning into 984 output records means something merged or dropped. Check that the column or key count matches. Spot check the fields that usually break: dates, identifiers with leading zeros, empty values that became null or the string "null", and any text with an accent. Open the downloaded file in the tool that will consume it, because a browser preview and a database loader disagree more often than people expect.

Keep the source. A conversion is reproducible only while the original text exists, and every format pair has at least one behavior that is not obvious from the outside. The tool does not store anything, so once the tab is closed the only copy is the one you saved.

Where the Tool Fits and Where It Does Not

A browser converter is the right instrument for inspection, for small and medium payloads, and for the moment when you need to see what a format actually contains. Paste an API response, switch it to CSV, and read the table. Take a YAML config, convert to JSON, and diff it against the deployed version. Change an SRT file to WebVTT and check the timings on screen.

It is the wrong instrument for a scheduled ETL job, for files that need validation against a schema, and for anything where the conversion must be audited later. Those cases want a script with an explicit type map and a validation step, not a text box. Knowing which case you are in takes about thirty seconds, and it saves the afternoon you would otherwise spend on a column that quietly lost its leading zeros.

xaxxon

Seattle, WA · SO reputation 19896 · Badges: 6🥇56🥈87🥉 · SO member since 2010