What happened: we ran an audit of every performance number on this site and checked each one against the test that supposedly produced it. What we found: a lot of them had no test behind them — a rig we never owned, a file our own tool refuses to open, another tool's number wearing this tool's name. What we did: deleted the ones with no receipt, corrected the ones that were wrong, and kept only the numbers a real run backs. Several of the honest replacements are smaller than what we'd been claiming. Why we're telling you: because "trust our numbers" is worthless unless we show our work — so here is the work, including the parts that make us look bad.
Most companies publish their benchmarks. Almost nobody publishes the benchmarks they were embarrassed to have published. This is that post.
TL;DR
We audited every throughput and capability claim on splitforge.app against its actual test record. Numbers with a real run behind them stayed. Numbers with no record — or a record that measured the wrong machine, the wrong file size, or a different tool entirely — were deleted or corrected, several of them downward. This post is the itemized list: the claims we killed, the ones that survived and why, and the method we used to tell them apart. The short version of our standard: a number is only as good as the receipt behind it, and a real number under a fake rig is still a fake claim.
Table of Contents
- The Benchmark That Started It: A CPU We Never Owned
- The Kill List
- The Survivors: Numbers That Kept Their Place
- How We Hunt Receipts
- What This Means If You're Evaluating Us
- FAQ
The Benchmark That Started It: A CPU We Never Owned
The whole thing started with a specification line. Our pages listed a test machine — an Intel Core i7-12700K with 32GB of DDR4 — and quoted numbers against it, including a tidy "10,001,000 rows in 28.4 seconds."
The problem: we never owned that machine. The numbers had been run on a different, more modest desktop (an Intel i5-12600KF with 64GB), and somewhere along the way the published rig drifted into something that sounded more impressive. Nobody sat down and decided to lie. A number got copied, a spec got "cleaned up," and a benchmark ended up attributed to hardware that didn't exist in our building.
That was the moment the standard changed. If we couldn't say which real machine produced a number and point to the run that produced it, the number didn't belong on the site. We applied that rule to everything — and it turned out the i7 was not the only ghost.
The Kill List
Here are the claims that didn't survive the audit. Every number below was, until recently, live marketing copy on this site.
We published another tool's number as our own. Our Data Cleaner page advertised a "Smart Clean All" throughput of 435,000 rows/second, complete with a screenshot showing millions of rows processed and a second-by-second timing breakdown. None of it was real. "Smart Clean All" had never been benchmarked. The 435K figure was borrowed — it was the deduplication speed from a different tool (Remove Duplicates), which does have a real record. We had taken a genuine number from one product and stapled it to a feature that had never been measured. That page now carries no throughput headline at all, because the honest answer was "we don't have one."
We ran a "Verified" benchmark on a Mac while claiming an Intel rig. The Excel-to-CSV converter page wore a "Verified Benchmarks" badge and quoted 109,005 rows/second. The fine print — which we hope nobody read too closely, because it embarrassed us — said the test ran on an Apple M1 Pro. Every other benchmark on the entire site runs on our Intel Windows desktop. This single page had been measured on completely different hardware and stamped "Verified" anyway. When we re-ran the actual converter on the actual machine, the honest number was about 31,500 rows/second — roughly a third of what the badge promised.
We headlined a benchmark for a file our own tool refuses to open. The Excel-to-JSON converter shouted 93,423 rows/second, "1 million rows in 10.7 seconds." To read an Excel file, that converter has to load the entire workbook into memory, so it caps input at around 14MB — a few hundred thousand rows. The one measured anchor behind the headline had been run at one million rows: a file size the product physically will not accept. We were advertising the speed of a job the tool declines to do. The page now explains why there is no single throughput number and tells you to split the file or convert to CSV instead.
We claimed "no file size limits" on tools with a hard memory ceiling. More than one page promised uncapped, RAM-bound processing — "no artificial cap," "supports up to 2GB," "Web Worker streaming." Several of those tools don't stream at all; they load the whole file into memory, which means the real ceiling is a heap wall around 12MB of Excel input, not two gigabytes. "No file size limits" wasn't optimistic. It was architecturally false, and testing with constrained memory proved that the very sizes we advertised would crash the tab.
We described a code path that doesn't exist. One page attributed its speed to "SIMD-accelerated string comparison in V8." There is no such code in the tool. The methodology note was invented to make a number sound more credible, and the number it was defending — hundreds of thousands of cell comparisons per second — didn't reconcile with the tool's own chart. The honest, re-measured figure for that comparison tool is about 12,800 rows/second.
We invented a medical code database. Our Data Validator claimed it validated healthcare codes "against the full FY2026 ICD-10 code set — roughly 72,000 codes — with a lookup table preloaded." It does no such thing. It runs a format check: it confirms a code is shaped like a valid ICD-10 or CPT code, which means a well-formed code that doesn't actually exist will pass. That's a genuinely useful check, and it's what a lot of import pipelines need — but it is not a 72,000-code database, and pretending it was is the kind of capability claim that gets a healthcare buyer in trouble. We also advertised "12 rule types"; the real number is 7.
We shipped a benchmark that was physically impossible. A data-masking page offered a downloadable per-run results file. One row claimed 1.4 million rows took 42 seconds while another claimed 10 million rows took 38 — the smaller job, somehow, taking longer than the job seven times its size. The file was fabricated boilerplate. The same tool advertised "50+ PII patterns"; the real count is 17.
And then we found the fingerprint. Once we knew what to look for, we found a copy-pasted methodology stamp on roughly eighteen tools — a tidy "tested over 10 runs, drop high and low, average the middle eight" ritual attached to numbers that had never seen ten runs. The tell was a typo that had been pasted along with everything else: "64GB RAM RAM." The machine name in the stamp was real. The methodology was decoration. That's the subtlest lie of the whole set, and the one that taught us the most: a real number wearing a fake methodology is still a fake claim.
Four performance pages ended up rebuilt with no throughput headline at all, because when we went looking for the receipt, there wasn't one, and we weren't willing to invent it a second time.
The Survivors: Numbers That Kept Their Place
Here's the other half of the story, and the more important half. Deleting numbers is easy. The point was never to scrub the site down to zero and call cowardice "honesty." The point was receipts. These numbers stayed exactly where they were, because a real run backs each one:
- 50,380 rows/second — Excel Splitter, splitting a one-million-row workbook by sheet in 19.8 seconds. It's the one measured baseline on that page, and every other figure there is explicitly labeled as calculated from it.
- 31,500 rows/second and 12,800 rows/second — the honest, re-measured replacements for the M1 and SIMD fabrications above. Smaller than what they replaced. Real.
- 228 million rows across a 10.4GB file, at constant memory — Data Validator, validated end to end with a heap profile to prove memory stayed flat. This one survived a provenance check specifically because the record existed, including a memory leak we found and fixed at exactly the 10GB mark, which is itself proof the 10GB run happened.
- A 10.4GB, 200-million-row aggregation at 235,000–270,000 rows/second — this one is instructive. The page used to show a fabricated scaling curve. We didn't just delete it; we replaced it with a real validation run that happened to exist. The fake number went down; the honest number took its place. That's the difference between hiding and correcting.
- A 10.8GB pattern-extraction run finding 141.9 million matches on an 18MB flat memory floor — certified with a forced-garbage-collection heap series, because "constant memory" is a claim you have to prove, not assert.
The pattern across every survivor: it points at a dated test, a validation gate, or an audit document. The pattern across every casualty: it pointed at nothing, or at someone else's run.
How We Hunt Receipts
We won't turn this into an engineering manual, but the method matters, because it's repeatable and you can hold us to it:
- Version control is a lie detector. Every number that ever appeared on the site is in our git history. Searching the history for a specific figure surfaces the exact moment it was introduced and, usually, the absence of any test committed alongside it. A benchmark with no harness next to it is a benchmark someone typed, not one someone ran.
- We test the ceiling, not just the happy path. For the "no file size limits" claims, we stepped memory down until the tool crashed, to find the real maximum. That's how we learned the advertised sizes were unreachable.
- We re-measure against the shipped product, in a real browser. Not a favorable lab build — the actual worker the actual page loads. Browser numbers came in consistently below the old lab figures, which is part of why several honest replacements are smaller.
- We grade two axes, not one. Every claim gets scored on whether the number is real and whether the rig and method are real. The "64GB RAM RAM" stamp is why the second axis exists: a true number under a fabricated methodology fails the audit just as hard as an invented one.
What This Means If You're Evaluating Us
You should trust a vendor's benchmarks slightly less after reading a post like this, and trust this vendor's remaining benchmarks slightly more. Both can be true. The numbers still on the site are the ones that survived us actively trying to disprove them.
But you don't have to take our word for even that — and this is the part we actually care about. Our whole product is client-side: files are processed in your browser and never uploaded. That's not just a privacy posture; it's independently checkable. You can open your browser's developer tools, watch the network tab while you run any tool, and confirm nothing leaves your machine — we wrote a guide to verifying exactly that, and we'd rather you run it than believe us. If you want to see the scale claims for yourself, the same 10-million-row browser demo runs on your hardware, not ours. And if you care where your data goes, the processing-location guide lays it out.
Honesty about a number is worth something. Building a product whose central claims you can verify without trusting us at all is worth more. We're trying to do both — and when we fall short of the first, this is the kind of post you can expect us to publish about it.