JSON conversion guide
Converting JSON is a data-model decision, not only a syntax change. Preserve meaning by defining how types, nulls, numbers, names, arrays, and nested objects map to the target format.
Start with valid, representative input
Validate the source before converting it. One sample can reveal observed fields and values, but it cannot prove which fields are optional or which values an API may send later. Use a schema or several representative samples when generated code or a database table will become part of a long-lived contract.
Preserve scalar meaning
JSON has strings, numbers, booleans, and null. Target languages usually have many numeric sizes and nullable types. A large integer may exceed JavaScript’s exact integer range, while a decimal price should not silently become a binary floating-point value in financial code. IDs with leading zeroes belong in strings. ISO date strings remain strings unless the contract explicitly defines their format and timezone.
Distinguish missing from null
A missing property can mean “not supplied,” while null can mean “explicitly empty.” Many generators infer both as optional from a small sample, which may weaken validation. Decide whether the target needs an optional field, a nullable field, both, or neither. In SQL, define nullability intentionally and do not infer a primary key from a property name alone.
Handle names and reserved words
JSON keys may contain spaces, hyphens, or names reserved by the target language. A converter should produce a legal identifier while preserving the serialized field name through annotations or tags. For example, a Go field can use a JSON tag and a Java field can use a serializer annotation. Keep the mapping deterministic so regeneration does not create noisy diffs.
Convert nested objects and arrays deliberately
Typed languages usually map nested objects to named types. Reuse structurally identical types only when they represent the same domain concept; shape equality alone does not guarantee semantic equality. Empty arrays provide no element evidence, and arrays containing mixed types may require a union, a generic value, or a rejected conversion depending on the target.
JSON to YAML and CSV
JSON to YAML preserves mappings, sequences, and scalar values, but comments and YAML-specific anchors do not exist in JSON. Quote ambiguous YAML strings such as values that resemble dates or booleans. CSV is flatter: choose a stable column set, decide how to serialize nested values, and reject inconsistent rows instead of silently shifting columns. The CSV and JSON Converter is best for arrays of similarly shaped records.
JSON to typed code and SQL
Generated TypeScript, Go, Python, Java, or C# models are a starting point. Review names, integer widths, optionality, and serializer annotations before committing them. For SQL, inspect table names, column types, lengths, nullability, and indexes. Generate migrations from an agreed schema rather than repeatedly inferring production tables from arbitrary payloads.
Validate the result with a round trip
Parse or compile the generated output, then serialize a representative value back to JSON when the target supports it. Compare meaningful values rather than formatting or key order. Add fixtures for nulls, empty arrays, nested objects, escaped Unicode, large numbers, and invalid input. A converter is trustworthy when its boundaries are explicit and regression-tested.
Frequently Asked Questions
Can every JSON document be converted to CSV without loss?
No. CSV is tabular, so nested objects, arrays, and mixed shapes need an explicit flattening or serialization rule.
Can a converter infer required and optional fields from one sample?
Not reliably. A sample shows observed values, not the complete contract; confirm optionality against schema or multiple representative samples.
Why do large JSON integers change after conversion?
Some runtimes use floating-point numbers that cannot exactly represent large integers, so preserve identifiers as strings or use an arbitrary-precision type.