Four conversion directions, paste input, and processing limits
This browser-based conversion utility provides four distinct manual conversion directions: CSV/TSV to JSON, CSV/TSV to XML, JSON to CSV/TSV, and XML to CSV/TSV.
The label "CSV ⇔ JSON/XML" denotes conversion pathways centered on tabular delimited text. It does not provide direct conversion between JSON and XML, nor does it support automated chaining between those two non-tabular representations.
Users select their desired transformation from the four supported options using the directional controls, and configure delimiter settings as either a comma or an authentic tab character.
When Tab (TSV) is selected, parsing and serialization execute with a true horizontal tab character (\t) rather than literal backslash-escaped characters.
All inputs must be manually typed or pasted into the provided text area. The application does not support file pickers, local disk uploads, drag-and-drop file ingestion, batch folder processing, or automated file downloads.
A sample button is provided to populate the active text area with a representative template that reflects the chosen direction and delimiter, allowing immediate observation of structure and parsing behavior before running user data.
Data processing is bound by explicit operational limits measured strictly in UTF-16 code units and record dimensions rather than grapheme clusters or raw file bytes.
The text input must not exceed 2,000,000 UTF-16 code units prior to parsing. Tabular processing enforces an upper boundary of 50,000 records (including the header row), at most 200 columns per row, and an aggregate maximum of 1,000,000 cells across the entire dataset (counting all header cells).
Serialization yields a maximum output size of 5,000,000 UTF-16 code units.
Conversion runs synchronously as a batch operation on the main browser JavaScript thread. Although structural and dimensional validations occur immediately upon parsing, processing near-limit datasets can monopolize thread execution, meaning there is no guarantee against transient interface freezing, memory pressure, or execution delays.
Modifying input text, switching options, loading samples, or changing conversion direction immediately wipes previous conversion results from the display.
Generation requires manually clicking the convert button, and copying relies on explicit clipboard handling with error guards.
CSV and TSV quotes, line breaks, whitespaces, and column count inspections
Delimited parsing evaluates input text to identify fields, row boundaries, and quotation encapsulation. The parser recognizes either comma or true tab delimiters according to configuration.
Input text may include a single leading UTF-8 byte order mark (BOM, \uFEFF), which the parser detects and strips before record analysis.
Character encoding transformations (such as Shift_JIS, EUC-JP, or arbitrary UTF-16 byte orders) are not performed; the source text must already be decoded into valid UTF-16 strings by the host environment.
Field quotation complies with strict delimited text rules. Within cells wrapped in double quotes, delimiters and line breaks are safely preserved as cell contents, and two consecutive double quotes ("") are normalized to a single literal double quote.
Whitespace surrounding field content is treated as literal data and is intentionally preserved without trimming. However, quoting rules are enforced strictly: unclosed quotes, premature characters immediately following a closing quote prior to a delimiter or line break, and misplaced quotation marks will immediately trigger a syntax error that halts conversion.
The parser rigorously validates tabular geometry. Every record must possess the exact same column count as the first record. Unequal row lengths, ragged lines, and truncated rows are firmly rejected with a localized error message in the user interface, without reporting the specific offending record index.
Input accepts CRLF, standalone LF, and standalone CR as valid record separators. In serialized CSV or TSV output, records are separated by CRLF (\r\n), and no trailing CRLF is appended to the final record.
When generating CSV or TSV from JSON or XML structures, fields that contain delimiters, double quotes, CR, or LF are enclosed in double quotes, with internal double quotes escaped as "".
Cells containing raw carriage return characters are preserved during output generation. Formula neutralization is intentionally omitted; expressions starting with symbols such as =, +, -, or @ remain intact, so tabular outputs should always be inspected before being loaded into spreadsheet applications.
Headers and type inference for CSV to JSON
When converting CSV or TSV to JSON, configuring the tool to treat the first row as headers designates that record as the key names for output JSON objects.
Each header entry is trimmed of leading and trailing whitespace. If a header field is blank after trimming, or if duplicate header names occur within the header record, parsing halts immediately with an explicit error.
When the header toggle is disabled, the first record is handled strictly as data, and conversion outputs a two-dimensional JSON array of arrays.
When type inference is disabled, all values remain strings. When active, type inference evaluates the parsed string content of each cell: lowercase true, false, and null are converted, while finite, safe numbers strictly conforming to JSON grammar with no leading zeros, plus signs, or surrounding whitespace are accepted as numbers.
Because quote status is not retained, a quoted cell such as "123" becomes the number 123, whereas values with surrounding whitespace remain strings.
Quoting a numeric cell cannot prevent numeric inference, and the toggle should be disabled when preserving textual codes or identifiers.
Values that do not satisfy strict numeric syntax—including unsafe integers, -0, NaN, and Infinity—are not rejected with errors, but simply stay strings.
Decimal numbers parsed into standard JavaScript numbers are governed by IEEE 754 double-precision floating-point arithmetic, meaning exact lexical precision cannot be guaranteed for arbitrary fractional values.
When the inferTypes option is switched off, all delimited cell values are emitted as raw JSON strings without exception, which prevents any unintended numeric conversion or boolean interpretation.
Object rows are constructed using null-prototype dictionaries (Object.create(null)). This prevents prototype pollution and ensures that special key names such as __proto__, constructor, and prototype are safely retained as regular properties.
Indentation for the resulting formatted JSON can be configured to 2 spaces or 4 spaces to suit developer inspection preferences. Output length is strictly checked against the 5,000,000 UTF-16 code unit ceiling before presentation.
Structure and missing values mapped from JSON to CSV/TSV
Converting JSON into tabular CSV or TSV formats accommodates a well-defined subset of data structures: single plain JSON objects, arrays of uniform plain objects, arrays of row arrays, and arrays of primitive values.
Single objects yield a one-row table with header keys, primitive arrays produce a single column without headers, and arrays of row arrays produce a grid where uneven row lengths are padded with empty strings to match the widest observed row.
Mixed arrays combining objects, arrays, or scalars in the same list, as well as completely empty objects or arrays, are rejected.
When converting an array of objects, the table header is assembled from the union of all top-level keys in the order they are first encountered across the dataset.
If a subsequent object lacks a particular key present elsewhere in the union, an empty cell is emitted. Nested objects and child arrays are not expanded into dotted or bracketed column hierarchies; instead, they are serialized using standard JSON stringification and stored within a single table cell.
For users requiring deep flattening into discrete columns, dedicated hierarchical flattening tools should be used.
The parser handles primitive values consistently. A JSON null value emits the literal text "null", whereas missing properties collapse into an empty string, thereby distinguishing an absent key from an explicit null value.
Scalar string representations, numbers, and booleans are mapped to their text equivalents before escaping.
Standard JSON.parse semantics govern initial document ingestion. Because of this, numerical values exceeding JavaScript safe integer boundaries or exhibiting extreme precision cannot have their original precision recovered once parsed into IEEE 754 floating-point values.
Top-level keys must exist to establish column headings, and total dimensions must remain within the 50,000-record, 200-column, and 1,000,000-cell thresholds.
Delimited serialization joins records using CRLF without appending a trailing CRLF, while properly escaping delimiters, line breaks, and quotes.
XML names created from CSV and the scope of reverting XML to tables
Converting delimited text to XML wraps records within a <root> element, each record in a <row> element, and each field in a column tag derived from the header.
Because XML element naming permits only a subset of characters, header names undergo conservative normalization: values are trimmed, characters outside Unicode letters, marks, digits, hyphens, underscores, and dots are replaced with underscores, invalid starting characters and reserved xml prefixes receive a field_ prefix, empty fields become field_{index}, and collisions are disambiguated with numeric suffixes.
Consequently, original header names cannot be guaranteed to round-trip identically.
All delimited values are serialized as XML text nodes. Characters such as &, <, >, ", and ' are escaped to standard XML predefined entities.
Carriage returns (\r) within cell values are converted to the numeric character reference to prevent XML parser end-of-line normalization from discarding them.
Values containing characters forbidden by the XML 1.0 specification or lone surrogate code points are strictly rejected.
Converting XML back to CSV or TSV accepts flat two-level structures where an arbitrary document root contains uniform arbitrary row elements enclosing field elements, such as <root> containing repeated <row> elements with <leaf> fields.
Documents with XML attributes, XML namespaces, nested child elements within fields, repeated tags in a row, mixed text and element content, comments, processing instructions, DOCTYPE declarations, or mismatched row tags are rejected as structural errors.
A preliminary lexical scanner inspects the document for DOCTYPE declarations prior to invoking DOMParser. Known parser error representations across Mozilla and WebKit/Blink engines are identified and treated as syntax failures.
Between row elements and between column elements, only structural text consisting exclusively of ASCII XML whitespace that includes at least one newline is omitted as table formatting convention, whereas non-whitespace text, structural CDATA sections, and whitespace lacking newlines (including a single space) cause structural rejection.
Leaf elements concatenate all child text and CDATA nodes into a single string value without preserving original boundaries. Empty elements and missing elements collapse into empty cells, and headers are ordered by union order of first appearance across rows, which can alter the original element sequence.
Result copying, synchronous processing, and data handling considerations
Conversion results appear directly in the output panel upon completion of manual execution. Clicking the copy button invokes the modern asynchronous Clipboard API with error handling and state tracking to prevent race conditions or false success indications.
Unlike automated real-time systems, output is not refreshed automatically as you type; any edit to input text, delimiter settings, header toggles, or conversion direction immediately clears the prior result.
Users must click the convert button manually to evaluate updated input.
All data conversion executes locally on the client device inside the web browser runtime. The converter component contains no logic to transmit pasted text or table outputs to external services for remote transformation.
However, users should understand that client-side execution boundaries apply specifically to this conversion component; static asset CDNs, site analytics, or advertising scripts present on the page operate under separate network contexts.
Users working with restricted or sensitive data should comply with internal data governance guidelines.
Because conversions execute synchronously on the main thread without Web Workers or stream-based chunking, massive workloads can briefly degrade interface responsiveness.
The utility enforces hard programmatic ceilings to protect stability: 2,000,000 UTF-16 code units for input, 50,000 records, 200 columns, 1,000,000 total cells, and 5,000,000 UTF-16 code units for output.
Exceeding any threshold produces an explicit descriptive error and halts processing without partial output.
Finally, exported CSV or TSV text files do not neutralize spreadsheet formula triggers. If fields originate from untrusted sources and begin with =, +, -, or @, spreadsheet software may interpret them as executable expressions upon opening.
Always verify table headers, dropped leading zeros, escaped quotation marks, and formula prefixes before importing generated delimited data into external spreadsheet tools.