Question 1

How accurate is the 537K rows/second benchmark?

Accepted Answer

Benchmarks were conducted February 2026 on Chrome (stable), Windows 11, Intel Core i7-12700K (3.6GHz), 32GB DDR4-3200 RAM. JSON→CSV direction, standard comma-delimited CSV input, 8 columns, 2-level nested JSON, 10M rows (~850MB). 10 runs per configuration with highest/lowest discarded and remaining 8 averaged. Results may vary ±15–20% depending on browser, available RAM, JSON nesting depth, column count, and whether type detection or nested flattening is enabled. Performance improves at scale due to the compiled row extractor and 60MB chunk batching — small files show lower throughput because startup overhead is proportionally larger.

Question 2

Why is JSON→CSV nearly 2.5x faster than CSV→JSON?

Accepted Answer

Fundamental asymmetry in the work required. JSON→CSV: read a JavaScript object, look up each property, escape the value, write a CSV line. The compiled row extractor (generated via new Function()) eliminates branching entirely — property lookups are baked into the function at schema parse time. CSV→JSON: parse CSV line by delimiter, build a JavaScript object with string keys and values, then serialize it back to JSON string. Object construction and JSON.stringify() are more expensive operations than CSV line writing. This asymmetry is consistent with how Python pandas and jq behave — JSON→CSV direction is always faster.

Question 3

Why is Excel→CSV so much slower than JSON→CSV?

Accepted Answer

XLSX is a ZIP archive of XML files (Open XML format). Before any CSV writing can begin, the entire file must be decompressed (unzip) and parsed as XML (DOM parsing). SheetJS handles this natively in the browser but the decompression + XML parsing accounts for 60–70% of total Excel conversion time. This is an inherent format constraint — XLSX cannot be streamed the way JSON or CSV can. The actual CSV write after parsing runs at ~94K rows/sec because it is equivalent to a CSV→CSV transformation. For large datasets in Excel format, export from Excel as .csv first (which Excel does natively), then use SplitForge on the resulting CSV file for full speed.

Question 4

What is the JSONL streaming architecture and why does it matter?

Accepted Answer

JSONL (JSON Lines) format stores each JSON object on its own line. The streamLinesFast() async generator reads the file in chunks via ReadableStream, yields individual lines without loading the full file into memory, and passes each line to JSON.parse() individually. This means a 2GB MongoDB export processes at the same memory footprint as a 1MB file — there is no intermediate state holding all objects simultaneously. Standard JSON array input requires the full array to be parsed before row extraction begins, which can cause memory pressure on files above 500MB. For large files, JSONL input is preferred over JSON array for this reason.

Question 5

Does nested JSON flattening work on any schema, or do I need to define the schema first?

Accepted Answer

Schema-free auto-detection. On first pass, SplitForge reads enough rows to determine all unique key paths in the nested structure using depth-first traversal. Once the schema is known, it compiles a zero-branch row extractor function specific to that schema. All rows after the first pass use the compiled extractor — no branching, no dynamic property lookup overhead. If row schemas vary (some rows have keys others do not), the extractor handles undefined values as empty strings. No configuration required — drop any JSON file and nesting is detected automatically.

Question 6

How does performance compare to Python pandas for the same conversion?

Accepted Answer

pandas.read_json() on a local file (no upload latency) with 10M rows typically completes in 12–25 seconds depending on schema complexity, comparable to SplitForge's 19-second result. pandas.read_csv() → .to_json() (CSV→JSON direction) is roughly 8–18 seconds for 10M rows. The key differences: SplitForge requires no Python environment, no dependencies, no command line, and works on any operating system in any browser. pandas wins on automation, batch processing, and regex-based transformations. SplitForge wins on instant no-setup conversion with zero upload for ad hoc or one-time workflows.

Question 7

What is the practical row limit?

Accepted Answer

No hard coded limit. Browser memory is the constraint — typically 2–4GB available to a browser tab. In testing: 10M rows of an 850MB JSON file produces a 250MB CSV output and stays within memory on most modern systems. Very large files (2GB+ JSON → large CSV) may require a 16GB+ RAM system. For files approaching the memory ceiling, JSONL output is recommended over JSON array (JSONL writes line-by-line without building a memory-resident array). Alternatively, use the CSV Splitter to break large files into smaller chunks, convert each chunk, then merge results.

Question 8

Can these benchmarks be reproduced?

Accepted Answer

Yes. Generate a test JSON file using Python (json.dumps() on a list of dicts), MongoDB data generator, or any JSON array generator. Open SplitForge Format Converter, drop the file, select JSON→CSV, run conversion. Time from file drop to download completion using browser DevTools Performance panel. Average 3+ runs on a cleared browser cache. Hardware differences change absolute numbers — a 16GB laptop will typically be 15–25% slower than the test machine. The relative speed advantage over upload-based tools (which add 15–45 seconds of upload latency) holds regardless of hardware.

File Size	JSON → CSV	CSV → JSON	Excel → CSV	Notes
1,000 rows	~22K rows/sec	~9K rows/sec	~8K rows/sec	Startup overhead visible at small sizes — worker init + file API dominates
100K rows	~210K rows/sec	~85K rows/sec	~50K rows/sec	Mixed data types, 8 columns
1M rows	~390K rows/sec	~160K rows/sec	~94K rows/sec	Standard CSV, nested JSON with 2-level nesting
5M rows	~490K rows/sec	~200K rows/sec	N/A (XLSX row cap)	ChunkWriter architecture reaches near-peak throughput
10M rows	~537K rows/sec	~220K rows/sec	N/A (XLSX row cap)	Peak throughput — zero-copy Uint8Array blob construction optimal
~1GB+ file	~520K rows/sec	~210K rows/sec	N/A	Maximum tested capacity (browser-memory dependent)

Format Converter Performance

Processing Time by File Size

Throughput at Scale

Why Local Processing Is Faster Than Upload Tools

Feature Performance Overhead

Calculate Your Time Savings

Benchmark Methodology

Honest Limitations: Where SplitForge Format Converter Falls Short

Browser-Based Processing

No Offline Mode (Initial Load)

Browser Tab Memory Limits

Browser Memory Ceiling (~1GB practical limit)

No Automation, API, or Scheduled Conversion

One File at a Time

Excel Output Capped at 1,048,576 Rows

No Schema Validation or Data Transformation

When to Use Python pandas / Excel Power Query Instead

You need automated, scheduled, or batch file conversion

You need to convert files larger than ~1GB regularly

You need complex schema transformation during conversion

You need to join multiple source files during conversion

Frequently Asked Questions