JSON Converter
Convert JSON or JSON Lines into tables and handoff text with record-path selection, flattening controls and warnings for sparse or risky data.{{ summaryHeading }}
{{ chartMessage }}
| # | {{ header }} | Copy |
|---|---|---|
| {{ rowIndex + 1 }} | {{ cell }} | |
| No record rows are available. |
JSON can hold a single value, a nested object, or an array of mixed values. JSON Lines stores one complete JSON value on each non-empty line. Both are useful for data exchange, but a destination such as CSV, SQL, or a Markdown table needs a clearer idea of what counts as a record and which nested values should become columns.
Most conversion mistakes begin before serialization. Selecting the wrong nested array can produce one giant row or an empty set. Flattening too aggressively can turn array positions into dozens of brittle columns, while leaving every nested object intact can fill cells with serialized JSON that spreadsheet users cannot filter naturally.
- Record selection decides which object or array becomes the handoff dataset.
- Flattening decides whether nested objects and arrays expand into path-based columns or remain inside cells.
- Target syntax decides how nulls, booleans, identifiers, quoting, and nested values are represented.
- Coverage shows whether every selected record actually contains each generated field.
A clean-looking table can still hide data loss. Blank cells may mean a field was absent, explicitly null, or intentionally rendered blank. Large integers are another concern because browser number parsing cannot represent every integer above 9007199254740991 exactly. Identifiers such as account numbers are often safer as JSON strings.
Conversion prepares a handoff; it does not create a destination schema, validate business meaning, or run database statements. Keep the original JSON, compare record counts and field coverage, and test the generated text with the system that will consume it.
How to Use This Tool:
Define the record set first, then choose how that set should be represented.
- Select Source format and paste JSON or JSON Lines, or load one local JSON, JSONL, or text file. Auto detection tries strict JSON before JSON Lines.
- Enter Record path only when the desired records are nested. Use dot and bracket notation or JSON Pointer, then confirm the resolved path and selected type.
- Choose Output format and set any target-specific XML or SQL names. Generated SQL contains
INSERTvalues only and must be reviewed before use. - Set Flatten objects and Flatten arrays for tabular targets. Keep nested data inside a cell when expanding every path would create unstable columns.
- Review Field coverage and Record table. Resolve sparse-field and number-precision warnings before copying or downloading the converted document.
Interpreting Results:
Record count is the number of selected array entries, or one when the selected value is not an array. Field coverage reports the percentage of those records that contain each flattened field. A value below 100% means at least one record lacks that field; it does not mean the present values are invalid.
Compare the resolved source format and selected path with your intent before trusting the document. Treat an unsafe-integer warning as a reason to compare the original source or preserve the value as a quoted string. For SQL, XML, YAML, HTML, or Markdown, validate the generated text with the destination parser because the converter cannot know its schema or policy.
Technical Details:
The conversion separates source parsing, record selection, structural reshaping, and target serialization. Keeping those stages distinct explains why JSON Lines and hierarchical outputs can preserve nesting while table-oriented outputs need a flattened record model.
Transformation Core:
| Stage | Rule | Output effect |
|---|---|---|
| Parse | Strict mode parses one JSON text. JSON Lines parses each non-empty line separately. Auto tries strict JSON first. | Produces one root value and records the resolved source format. |
| Sort | Optional ascending or descending key sorting is applied recursively before record selection. | Makes object-key order repeatable for comparison-oriented output. |
| Select | An empty path keeps the root. Dot/bracket or JSON Pointer tokens walk objects and array indexes. | An array becomes multiple records; any other selected value becomes one record. |
| Reshape | Objects and arrays either expand recursively into path-based fields or remain as serialized values. | Creates the header set, row cells, and field-coverage counts used by table targets. |
| Serialize | JSON Lines uses selected records; XML and YAML use the selected value; CSV, TSV, HTML, Markdown, and SQL use the reshaped rows. | The chosen target determines quoting, names, null rendering, and whether hierarchy remains visible. |
Path and Flattening Rule Core:
| Rule | Exact behavior |
|---|---|
| Dot and bracket path | Dots separate object keys and brackets select an object key or non-negative array index, as in items[0].records. |
| JSON Pointer | The path begins with /; ~1 represents a slash and ~0 represents a tilde. |
| Object flattening | Nested keys join with dots. When disabled below the record root, the nested object remains serialized in one cell. |
| Array flattening | Array positions become bracketed indexes. When disabled, the array remains serialized in one cell. |
| Headers | Headers follow first appearance, then may be preserved or normalized to snake_case, kebab-case, or camelCase. Collisions receive deterministic numeric suffixes. |
| Null cells | Table outputs use the literal null by default or an empty cell when blank-null mode is enabled. |
| Coverage | For each header, present-record count divided by total record count is rounded to two decimal places. |
CSV follows comma quoting with doubled quote characters; TSV replaces tabs and line breaks inside cells with spaces. XML names are sanitized and prefixed when they cannot begin with a valid name character. SQL identifiers are normalized and quoted for the selected dialect, while strings escape single quotes and booleans follow that dialect's literal convention.
Source text is limited to 200,000 characters, and a loaded file may be no larger than 2 MiB. Record paths are limited to 240 characters. XML element names accept 1 through 40 characters, SQL table names accept 1 through 80, indentation accepts 0 through 8 spaces, and the visible preview accepts 10 through 500 rows without shortening the downloaded text.
Privacy and Safety Notes:
Source text and loaded files are converted in the browser rather than uploaded. The generated output can still expose every selected value, including secrets or personal data. Review the record path before sharing, and treat generated SQL as text for inspection rather than as a substitute for parameterized database imports, constraints, or backups.
Worked Examples:
Nested API records to CSV
A response stores rows under data.items. Selecting that path and flattening objects turns customer.name into a column, while leaving arrays unflattened keeps each tag list in one cell. Field coverage exposes optional keys before the CSV is imported.
JSON Lines to reviewed SQL
One object per line is pinned as JSON Lines and converted to PostgreSQL INSERT text. The record count is checked against the source lines, long numeric identifiers remain quoted strings, and the statements are reviewed in a transaction-safe database workflow rather than run blindly.
References:
- RFC 8259: The JavaScript Object Notation Data Interchange Format, RFC Editor, December 2017.
- RFC 6901: JavaScript Object Notation Pointer, RFC Editor, April 2013.
- JSON Lines, JSON Lines documentation.