JSON to CSV Converter

Nested JSON is flattened using dot notation to create CSV column names. Example: {user: {name: "John", age: 30}, city: "NYC"} becomes three CSV columns: user.name, user.age, city. Arrays in JSON: converted to JSON string in CSV cell (cannot represent arrays in flat CSV), or each array item becomes separate row (one-to-many expansion option). Deep nesting: object.inner.deep.property becomes column name, can result in many columns if structure is deeply nested. Alternative handling: stringify nested objects as JSON strings in single CSV cell (preserves structure but not spreadsheet-friendly), manual flattening before conversion for control over column names. CSV limitation: inherently flat format, complex nested structures lose their hierarchical organization. Best for: relatively flat JSON objects with 1-2 levels of nesting.

Tool collects ALL unique keys from all JSON objects to determine CSV columns: Missing keys: result in empty cells for objects lacking that key, ensures every object becomes complete CSV row with all possible columns. Example: [{name: "Alice", age: 25}, {name: "Bob", city: "LA"}] creates 3 columns (name, age, city) - Alice row has empty city, Bob row has empty age. Column order: alphabetical by key name (consistent), or order of first appearance, or custom sort option. Many columns problem: if dataset has 100+ unique keys total, CSV becomes very wide with mostly empty cells. Solutions: filter/select specific keys before conversion, preprocess JSON to normalize structure, split into multiple CSVs by object type. Best practice: validate JSON structure consistency before conversion, clean data to remove unnecessary keys, use consistent schemas in source data.

CSV uses RFC 4180 standard for proper escaping: Commas: values containing commas are wrapped in double quotes ("value, with, comma"), quotes preserved in actual data vs delimiter commas. Double quotes: escaped by doubling ("He said ""hello""" represents: He said "hello"), prevents quote from ending the field prematurely. Newlines: values with newlines are quoted (multi-line text becomes "line1\nline2"), CSV row only ends on unquoted newline. Example: {name: "Smith, John", bio: "He said \"hi\""} → "Smith, John","He said ""hi""". Encoding: UTF-8 with BOM (byte order mark) ensures Excel opens international characters correctly, alternative: ASCII with escaped Unicode. Import warning: Excel sometimes mishandles CSV quoting with complex data, LibreOffice Calc and Google Sheets are more compliant. Not CSV-safe: binary data (use Base64 encoding first), very complex nested structures (use JSON instead).

CSV is text-only format - no native type information, so conversion requires type inference: Numeric detection: strings like "123" or "45.67" converted to numbers, empty strings become null, "0" stays 0 not false. Boolean detection: "true"/"false" strings become boolean values, case-insensitive (TRUE, False work too), "yes"/"no" can be configured. Date detection: ISO format "2024-01-15" or "2024-01-15T10:30:00Z" parsed to Date objects (optional), ambiguous formats (01/15/2024 vs 15/01/2024) can cause issues. Null handling: empty cells become null, empty string "" vs null distinction lost in CSV. Type preservation issues: numbers with leading zeros ("007") become 7 (use string type), large integers lose precision (JavaScript 53-bit limit), scientific notation (1e5) auto-converted. Solutions: provide type schema/hints for accurate conversion, keep everything as strings (safe default), manual post-processing for specific fields. Always validate converted data before using in production.

Client-side processing means browser memory is the limit: Practical limits: 10-50MB JSON/CSV files work smoothly on most devices, 50-200MB may cause slowdown or freezing (depends on device), 200MB+ risk browser tab crash or out-of-memory errors. Performance factors: nested JSON takes longer to flatten, inconsistent structure (many unique keys) slows processing, preview rendering is expensive for 10K+ rows. Optimization strategies: disable preview for large files (faster), process in chunks/streaming (avoid loading entire file), use Web Workers (avoid UI freezing), consider server-side conversion for huge datasets. Alternative tools: command-line tools (jq, csvkit) handle GBs easily, database imports for massive datasets, streaming parsers for real-time processing. Our tool best for: quick conversions <50MB, ad-hoc data transformations, one-off imports/exports, when installing software is not an option. For regular large-scale conversions, automate with scripts.

JSON structures require different handling: Array of objects (most common): [{id: 1, name: "A"}, {id: 2, name: "B"}] - directly maps to CSV rows (each object = one row), headers from object keys, this is ideal CSV structure. Object of objects (keyed): {user1: {name: "A"}, user2: {name: "B"}} - need to extract keys as ID column, convert to: [{_key: "user1", name: "A"}, {_key: "user2", name: "B"}], or use keys as row identifiers. Single object (one row): {name: "A", age: 30} - creates single CSV row, headers from keys, useful for config exports. Nested arrays: {users: [{name: "A"}, {name: "B"}]} - extract users array first, flatten outer object properties to each row. Tool behavior: if root is array, assume rows, if root is object, check if values are objects (convert to rows), if root is single object, create one-row CSV. Pre-process complex structures before conversion for control over output format.