CSV File Comparator

Introduction:

Two exports can contain the same business records without looking identical. Columns may move, a new field may appear, numeric text may gain trailing zeros, timestamps may use different offsets, or rows may arrive in a different order. A useful CSV comparison has to separate harmless representation changes from changes to the records themselves.

Reliable reconciliation starts with a key. A customer ID may identify one row, while a monthly ledger may need a composite key such as account ID plus period. Keys connect the same record across both sources even when row order changes. Blank keys cannot identify anything, and duplicate keys make one-to-one matching ambiguous, so they should remain visible rather than being paired by guesswork.

Schema change

A column was added, removed, or moved relative to the other source.

Added or removed row

A unique key appears in only the updated or original source.

Changed field

The same unique key exists in both sources, but a shared non-key value differs under the selected matching rules.

Duplicate or rejected row

A key is repeated, blank, null-like, or the record cannot be parsed safely enough for matching.

Literal text comparison is appropriate when formatting is part of the requirement. Normalized matching is better when 10, 10.0, and 1e1 should count as the same number, or when equivalent ISO timestamps should compare as the same instant. Normalization must be chosen deliberately because trimming spaces, ignoring letter case, or treating blank and NULL as equal can also hide a meaningful source-system difference.

CSV is a family of delimited-text conventions rather than one perfectly uniform file shape. Delimiter, quote character, header presence, and character encoding all affect parsing before any row can be compared. Confirm those choices first; otherwise a clean-looking report may be comparing the wrong columns or damaged text.

How to Use This Tool:

Treat Source A as the original export and Source B as the updated export, then choose rules that match the data contract.

1. Upload or paste both sources. Each file or text source may contain up to 1 MiB, 20,000 records, 100 columns, and 500,000 cells.
2. Set Source delimiter, Headers, Quote character, and File encoding. Auto delimiter detection resolves each source independently; pasted text is already decoded.
3. Enter exact Key columns, separated by commas for a composite key. In headerless mode, use generated names such as column_1.
4. Choose Value matching. Use strict for literal text, normalized for trimmed numeric, null, and ISO-date equivalence, or normalized plus case-insensitive text.
5. Run Compare sources. If a key column is missing, an encoding is invalid, or a row has the wrong field count, correct the named source and run again.
6. Review schema findings, change counts, duplicate groups, rejected rows, and field-level evidence before acting. Showing unchanged records affects only the on-screen ledger, not the comparison.

Interpreting Results:

Changed, added, and removed counts describe unique-key records. Changed fields count individual shared columns whose normalized values differ. Schema rows are reported separately, so an added column does not automatically make every matched record a changed row.

Duplicate-key groups and rejected rows need human review before totals are treated as a complete reconciliation. No match is guessed when either side contains more than one record for a normalized key. A zero changed-row count can therefore coexist with unresolved duplicate or rejected records.

• Check resolved delimiters and schema changes before trusting row counts.
• Inspect the exact before and after values for changed fields, especially when strict and normalized profiles disagree.
• Resolve every blank key, duplicate group, parse rejection, and unexpected schema change before using the report as proof that two systems agree.

Technical Details:

Each source is decoded and parsed before matching. Auto detection tests comma, tab, semicolon, and pipe delimiters and chooses the best consistent record shape for each source. Quoted fields may contain delimiters and line breaks; a quote inside a quoted field is represented by a doubled quote. Every data row must resolve to the same number of fields as the header or generated header row.

Transformation Core:

Rule Core:

Normalized decimal matching removes insignificant leading and trailing zeros and accounts for scientific notation, so 10.00 and 1e1 compare equally. Date matching accepts valid ISO calendar dates and timezone-bearing timestamps; timestamps are reduced to the same instant before comparison. Strict matching leaves cell text untouched, including spaces, case, number formatting, and date representation.

Spreadsheet-directed values beginning with =, +, @, or − are prefixed with an apostrophe when written to the evidence CSV. This reduces formula execution risk when the report is opened in spreadsheet software, while leaving the on-page before and after evidence readable.

Privacy and Limits:

Files and pasted text are decoded and compared in the current browser tab; source data is not uploaded or placed in the query string. Treat downloaded reports and copied rows as new copies of the source information.

• The comparison is key-based, not a fuzzy matcher. Misspellings or changed identifiers appear as removed and added records unless the chosen key remains stable.
• Normalized equality can hide formatting differences by design. Use strict matching when spaces, capitalization, numeric spelling, or timestamp text is significant.
• The evidence ledger is limited to 50,000 rows and its generated CSV to 8 MiB; narrow oversized comparisons before rerunning.
• Protect sensitive exports according to their data classification, including clipboard history, downloads, and any later spreadsheet copies.

Worked Examples:

References:

• RFC 4180: Common Format and MIME Type for CSV Files, RFC Editor, 2005.
• Common Format and MIME Type for Comma-Separated Values Files, Internet-Draft, 2024.
• Encoding Standard, WHATWG Living Standard.