CSV Data Validator

A CSV Data Validator checks a table against requirements you explicitly provide. A file can be structurally valid CSV while still containing missing customer identifiers, duplicate keys, out-of-range quantities, or dates that a destination cannot interpret. Parsing answers whether the text forms a table. Validation answers whether the records satisfy the selected rules. This tool reports problems without automatically trimming, converting, deleting, or repairing the original cells.

Start by obtaining the destination's actual requirements. Decide which fields are mandatory, what makes a key unique, which values are allowed, and whether a rule should block import or merely raise a warning. A useful rule should have an understandable passing condition. A successful local validation run means only that those configured checks passed on the chosen scope; it does not guarantee acceptance by an external platform with additional business rules, permissions, reference data, or changing requirements.

Use Choose files for CSV or TSV, or Paste a table for copied data. Confirm parsing so that headers, quoting, and record boundaries match the source. The tool keeps cell text as text, including leading zeros and long identifiers. If a note contains a quoted newline, it remains inside one logical record. Problem locations refer to those logical records and retain the source file rather than pretending that every record occupies one physical text line.

Select Add validation rule. Choose Check type, the Checked column or Unique key columns, and Severity. Enable rule determines whether the rule participates in the run. Move up changes its order, and Remove deletes it from the configuration. Rules do not progressively change the input: each enabled check inspects the same source values. A record can therefore produce several meaningful problems, which remain separate report rows rather than being compressed into a single unexplained failure flag.

Required checks the configured empty definition. Missing cells and empty strings are empty initially; whitespace-only cells and explicit marker words require deliberate configuration. Zero, false, NULL, and N/A are not all treated as missing automatically. If a destination considers a literal marker invalid, either add it to the empty definition for a required rule or define an allowed-value check that expresses the intended contract. Do not redefine legitimate zero quantities as missing merely to simplify the report.

Unique compares one or several selected columns. It uses strict text comparison unless you enable Ignore case or Trim surrounding whitespace for that rule. Those options affect comparison only; the stored source text is unchanged. Composite keys retain component boundaries, so a separator inside a customer code cannot collide with a different customer-and-region combination. Missing key components are excluded from uniqueness by default. Required determines whether they are permitted; Include empty values in uniqueness is an explicit alternative policy.

Consider identifier values A, A, and an empty field. Add one Required rule and one Unique rule for that identifier column, keeping empty values excluded from uniqueness. The two A records each receive a duplicate-key problem because both belong to the same duplicated group. The empty record receives a required problem. The report therefore contains three blocking issues affecting three records, not one issue on the last duplicate and not an extra meaningless type failure for the empty value.

Change the Unique rule to Warning and run again. The required problem still blocks its empty record, while the duplicate A records receive warnings. Passed records means no blocking error under the current rules; it can include records with warnings. Use the severity filter when reviewing that distinction. If your import must reject warnings too, configure those checks as Blocking error. A warning label should express a real business decision rather than obscure an unresolved requirement.

Field type supports text, number, integer, and the literal boolean values true and false. Text length is measured in Unicode code points, with inclusive minimum and maximum bounds. Code points are not always the same as displayed characters: an emoji sequence or a combining accent can contain several. Allowed values compares exact listed strings. It does not translate labels, guess abbreviations, or automatically standardize capitalization; use a separate confirmed standardization step if those transformations are intended.

Numeric range uses the shared numeric interpretation controls. Confirm decimal and grouping separators, signs, currency tokens, and percentage meaning before checking a bound. The range limits themselves are plain decimal values with a dot. A minimum greater than its maximum, malformed bounds, and unconfirmed numeric interpretation are configuration errors. Empty values normally skip type and range checks to avoid redundant problems; a Required rule is responsible for stating that a number must actually be present.

Date format uses the same explicit source-pattern and calendar checks as the date converter. Invalid dates and conflicting pattern interpretations become validation problems without rewriting their original text. Calendar dates remain separate from clock times. An offset-bearing timestamp and a local clock reading cannot safely be ordered as instants unless the zone meaning is established. Configure Date meaning and the source rules consistently before using a relationship involving time.

Number: left ≤ right checks two interpreted numeric fields, such as minimum and maximum quantity. Date: left ≤ right can express that a start date is no later than an end date. If either nonempty value cannot be interpreted, the relationship reports an interpretation problem instead of silently comparing its raw spelling. Empty operands skip the relationship; add Required rules for both fields if neither may be missing. These limited relationships do not implement arbitrary formulas or execute scripts from the file.

Run and review executes enabled rules over the selected Processing scope. The validation review panel can filter by severity, field, and rule. Each issue includes the record identity, field, original value, rule identifier, check kind, severity, reason, and source location. Opening a source link shows the underlying record. A bad amount and an invalid date on the same row remain two independent issues, making it possible to correct both without repeatedly rediscovering the next error.

The report distinguishes issue counts from failed-record counts. Ten issues might affect ten different records or several problems on one record. Result-view search narrows only what the grid displays; it does not silently change export scope. Use Passed records, Failed records, or Validation issues explicitly in Export new copy. Source data stays available even when the configuration is blocked by a deleted or missing column. A missing binding cannot produce a reassuring all-passed result.

Save rules records ordered checks, enabled states, severity, comparison policies, and interpretation settings. Load rules requires matching field structure and remaps bindings to the current columns. Review the business meaning again for a new file, even when its headers happen to match. A source can change a decimal convention without renaming its amount column. Rule templates may contain sensitive field names and allowed values; inspect them before sending them outside your organization.

First 20 records only is useful for checking that a rule expresses the intended condition, but cannot establish full-file uniqueness or total error counts. A duplicate may lie outside the sample. Sample reports carry a scope label and SAMPLE filename, and cannot be applied as the complete workflow result. Switch to All records and rerun before claiming that the file passed. Editing any input or rule makes previous results stale, preventing an old successful report from being downloaded as though it covered the new settings.

The tool can export passed records, failed records, the complete problem list, or the configuration report. Generated CSV and TSV text is read back for structural and value verification before download is enabled. Formula-prefix protection is an explicit export choice that can change dangerous-looking prefixes. The validator itself does not execute cell formulas, HTML, or scripts. Opening the downloaded file in another application can still trigger that application's own interpretation rules, so import identifiers and other exact strings as text when appropriate.

After reviewing failures, continue to a suitable cleaning, date, or number tool, apply only the intended changes, and rerun validation. Preserve reports when an audit needs to explain both the original failure and its resolution. Cancel task terminates active processing while preserving the source and applied workflow. Files remain in page memory and are cleared by refresh or closing. Large rule sets can create more issue rows than input rows, so report limits and the execution timeout may require splitting the work into smaller, explicitly scoped checks.