Format and validate against RFC 4180 by section, with output verified by reading it back
Initializing in your browser…
Remove duplicate rows with equality as a stated choice: case, spaces, accents and numbers each their own switch, and the rule in force shown
Validate columns against rules that name their definition: the email rule browsers enforce, a URL scheme allowlist, calendar-checked dates, and every failure explained
Chain 34 cell transformations, each stating its own rule, with anything it could not do reported rather than passed through unchanged
A file arrived with LF line endings, one ragged row, and a product name containing a comma. You need something a strict importer will take.
Input
name,qty\n"Widget, deluxe",5\n"Gadget",10,extra\n
Output and findings
name,qty\r\n"Widget, deluxe",5\r\nGadget,10\r\n
§2.1 In the file you pasted: records are separated by LF.
RFC 4180 section 2.1 specifies CRLF.
§2.4 In the file you pasted: 1 row does not have 2 fields.
Section 2.4 says each line SHOULD contain the same number
of fields; "should" is why this is a warning.The comma inside "Widget, deluxe" keeps its quotes because section 2.6 requires them, the line endings become CRLF per section 2.1, and the ragged row is named rather than silently squared up. Each finding cites the section and quotes the sentence it comes from. The output is checked by reading it back with a separate parser, so "it looks right" is not the test.
Clean up a CSV and get told exactly where it departs from RFC 4180, quoting the sentence in the specification each finding comes from. The output is verified the only way that settles it: by reading it back and checking the table is the one that went in.
This repository already carries a blog post explaining RFC 4180 (Parsing CSV Correctly), and checking this tool against its own post's claims was where this pass started. The post and the tool disagreed in three places, and the post was right every time. Every finding below is from a round trip: the table goes in, the tool writes it, and Python's csv module, a separate implementation, reads it back.
A quote style of "no quotes" wrote a field containing the delimiter without quoting it, so `Widget,holds, the delimiter` read back as three fields instead of two, and the file could not be recovered at all. Two of the five shipped presets set that style. Section 2.6 says fields containing line breaks, double quotes and commas SHOULD be quoted, and a writer that skips it produces something no reader can undo. Quoting is now a minimum rather than a preference: asking for no quotes gets you no quotes anywhere it is safe, quotes where it is not, and a note saying how many fields and which one.
The custom quote character went into `new RegExp(char, "g")` unescaped. Setting it to a vertical bar makes an empty alternation that matches at every position, and the output came back unreadable; any regular expression metacharacter does something similar. There is no regular expression in the escaping any more, and all nine metacharacters are tested.
Records were separated by LF with no way to ask for anything else. Section 2.1 says CRLF, which is now the default with LF available.
Two more came out of the round trip. Trimming whitespace was on by default, so ` padded ` arrived as `padded`; section 2.4 says spaces are part of a field and SHOULD NOT be ignored, so trimming is still there and is no longer the default. And column padding was written into the fields, so a padded file did not read back. Moving the padding outside the quotes does not fix that, which is worth knowing because it is the obvious thing to try: measured, a strict reader REFUSES a field with padding after its closing quote, and a lenient one hands the spaces back as data. Padding is now labelled for what it is, a layout for reading by eye, with a warning that the file is no longer a faithful CSV.
The validation half reports findings by section rather than as a verdict. Ragged rows cite section 2.4 and quote the sentence, including the word SHOULD, which is why they are a warning and not a refusal. An unquoted field containing a double quote cites 2.5. LF line endings cite 2.1, and mixed line endings are a warning rather than a note. A missing final line break cites 2.2 and is explicitly fine. A byte order mark is reported, because RFC 4180 does not mention one and a reader that does not strip it puts it inside your first column name. Both the file you pasted and the file produced are checked, so squaring up a ragged file tells you it arrived ragged rather than quietly hiding it.
Get output that is verified to read back into the table that went in, with CRLF line endings and the quoting the specification requires.
The findings cite the section and quote the sentence, so a ragged row or an unquoted quote is identified rather than reported as "invalid".
Read a semicolon file and write a comma one, with fields that contain the new delimiter quoted so the result survives.
Write a UTF-8 byte order mark so Excel reads the encoding correctly instead of showing mojibake.
Because leaving those quotes off would produce a file nobody can read back. A field containing the delimiter, a quote or a line break has to be enclosed (RFC 4180 section 2.6), and the tool tells you how many fields that applied to and shows one. Everything else is left unquoted.
RFC 4180 section 2.1 specifies CRLF as the record separator. Almost every reader accepts a bare LF as well, which is why it is offered, and choosing it produces a note rather than a warning.
Section 2.4 says spaces are considered part of a field and SHOULD NOT be ignored. Trimming is a useful cleanup and it is still one click away; it just is not something that should happen to your data without you asking.
Yes, and the tool will warn you that the result is no longer a faithful CSV. Padding cannot be made to round trip: measured with Python's csv module, a strict reader refuses a field padded after its closing quote and a lenient one hands the padding back as part of the value. Use it for reading by eye, not for a file another program will parse.
It writes the three bytes EF BB BF at the front. Excel needs them to recognise a UTF-8 file and will otherwise show accented characters as mojibake. RFC 4180 does not mention a BOM at all, so the tool reports one when it finds one rather than assuming.
Because section 2.4 says each line SHOULD contain the same number of fields, not MUST. The tool tells you which rows differ and how many fields they have, and lets you square them up.
Rows and columns are parsed and transformed in memory in your browser. No record ever reaches a server.