CruxDevCruxDev Tools Prompts
dev Utility • Zero-Server Privacy • 100% Client-Side

JSON Lines (NDJSON) ⇄ JSON / CSV Converter

Convert JSON Lines to a JSON array or CSV and back - nested records flattened to dot-path columns, malformed lines reported by line number, all in your browser.

Overview

Converts JSON Lines (NDJSON) - one JSON value per line, the format behind log pipelines, BigQuery loads, and streaming APIs - to a JSON array or CSV, and back again. Malformed lines are reported by line number instead of aborting the batch, and CSV output flattens nested records to dot-path columns so deeply nested events become readable spreadsheets.

How It Works

Pick one of the four modes: JSONL to JSON, JSONL to CSV, JSON to JSONL, or CSV to JSONL. Paste your data and the conversion runs as you type. Bad lines keep converting - the good records appear and every failing line is listed with its number and the parser's actual error, so one corrupt log line never costs you the whole file.

Step-by-Step Usage Guide

  1. Choose the conversion direction that matches where your data is and where it is going.
  2. Paste the input; the output updates live with any bad lines called out by number.
  3. Fix or ignore the reported lines - valid records convert regardless.
  4. Copy the result for your loader, spreadsheet, or log file.

Technical Specifications & Standards

JSON Lines is deliberately line-delimited: each line is an independent JSON value, which is what makes the format streamable - a reader can process records without holding the whole file, and a truncated file loses only its last line. That independence is why this tool converts per line instead of parsing once. For CSV, records are flattened recursively: {user:{name:'Ada'}} becomes a column user.name, and arrays serialise as JSON text rather than being exploded into columns you did not ask for; headers are the union of every record's keys, in first-seen order. On the way back from CSV, cells are typed conservatively: strict number patterns become numbers, true/false become booleans, and empty cells become null - everything else stays a string, because guessing harder than that is how '0123' becomes 12. JSON-to-JSONL mode splits a top-level array into one line per record, the exact operation you need before appending records to a log or loading them into BigQuery.

Targeted Use Cases

  • Previewing a .jsonl export from logs or an analytics pipeline before loading it into a warehouse.
  • Turning a JSON API response array into JSONL for streaming ingestion.
  • Giving a non-technical colleague a CSV view of an event log with nested fields flattened.
  • Converting a CSV dataset into JSONL records for a vector database or ML training script.

Notes & Gotchas

  • Keep one JSON value per line with no trailing commas - pretty-printed multi-line JSON is not JSONL; use JSON-to-JSONL mode to fix that.
  • Check the dot-path column names before sharing CSV output; deep nesting produces wide tables.
  • Treat type coercion deliberately: IDs with leading zeros should stay strings, so verify what the CSV round trip did to them.
  • For huge files, sample the first few thousand lines here to validate structure, then run the full file through your own pipeline.

Frequently Asked Questions

What is the difference between JSON and JSON Lines?

A JSON file is typically one value, pretty-printed across many lines. A JSON Lines file is many values, one per line, each independently valid. The line-per-record shape is what makes JSONL streamable and appendable.

Why do nested fields become columns like user.name?

CSV has no nesting. Flattening to dot paths preserves the full structure in the column names instead of silently dropping it; arrays serialise as JSON text for the same reason.

One bad line stopped my old converter - what happens here?

Nothing stops. Valid records convert, and each invalid line is reported with its line number and the parser's message, so you can fix exactly the lines that are broken.

Does it upload my data?

No. All parsing and conversion run in your browser. Log files and event exports often contain sensitive fields; they never leave your machine.