CSV validator and data quality profiler

Data conversion

Loading tool

Preparing the tool. The remaining time is not yet known.

All processing for this tool happens in your browser. Your input is not sent to a server.

About this tool

Inspect a CSV or TSV export before cleaning, joining or importing it. This local profiler combines quoting, header and row-width diagnostics with per-column missingness, exact distinct values and duplicate counts. Select composite keys, numeric columns or a strict date format only when those checks match your data. Original strings stay unchanged, including leading-zero identifiers and long integers. Counts and row positions help you investigate; the tool does not invent an overall quality score or certify business correctness. Cell-value examples are off by default, and analysis runs in a cancellable browser worker.

Common uses

Check a customer export for absent trailing fields, empty strings, whitespace-only cells and an explicitly configured N/A marker without treating them as interchangeable.
Find repeated complete rows or repeated order_id + line_id keys before comparing snapshots or joining tables. Count the repeated groups and extra rows without deleting anything.
Inspect likely column types, then opt into numeric summaries for known measurement columns and strict calendar checks for known date columns before choosing cleaning rules.

How to use it

1.Paste delimited text or choose a file with UTF-8, UTF-16 LE or UTF-16 BE encoding. Select comma, tab, semicolon or vertical bar and whether the first record is a header. Use the correct settings before interpreting any result; a quoted line break belongs to one CSV record, not a new data row. Configure any exact null-marker strings your source uses. They are case-sensitive whole-cell matches; there is no implicit trimming, case folding or automatic null conversion. Select key columns by position if you need a composite-key duplicate check. Repeated or blank header names do not make positional selections ambiguous.
2.Enable numeric statistics only for columns that represent quantities. Choose the exact date pattern used by the source; it informs date heuristics across all columns. Add per-column required, unique or type rules when you know the expected contract, using a date type rule for specific date columns. Enable value examples only if you want original cell text in the preview and report; default reports retain counts, positions, headers and settings without example cells.
3.Run the analysis and review structural issues, per-column counts, likely-type conflicts, complete-row duplicates and selected-key duplicates. A suggestion is evidence to review, not a command to change data. Fix malformed quoting before expecting a complete profile. Changes to the source or settings invalidate the old result; run again to see current findings. Download the JSON or CSV quality report after reviewing its privacy setting. Keep CSV formula protection enabled; raw CSV is an explicit choice with a warning. JSON keeps any included strings as data. Exports describe findings rather than a cleaned copy of your table. Use the CSV viewer and cleaner for deliberate repairs, then return here to check the result. Cancel stops current work; Clear removes the current input and result from the tool.

Reproducible CSV quality checks

Keep four missing-value states separate

{
  "input": "id,value\n1\n2,\n3, \n4,N/A\n5,null\n6,n/a\n7,N/A",
  "options": {
    "delimiter": ",",
    "header": true,
    "nullMarkers": [
      "N/A"
    ],
    "keys": [],
    "numericColumns": [],
    "dateFormat": "YYYY-MM-DD",
    "constraints": [],
    "includeExamples": false
  }
}

{
  "summary": {
    "rows": 7,
    "columns": 2,
    "cells": 13,
    "missing": 1,
    "empty": 1,
    "whitespace": 1,
    "nullMarker": 2,
    "raggedRows": 1
  },
  "columns": [
    {
      "index": 0
    },
    {
      "index": 1,
      "present": 6,
      "unique": 5,
      "duplicateValues": 1,
      "missing": 1,
      "empty": 1,
      "whitespace": 1,
      "nullMarker": 2
    }
  ]
}

The second column has one absent field, one existing empty string, one whitespace-only value and two exact N/A markers. Lowercase n/a and literal null remain ordinary text. All six present strings contribute to exact distinct counts, including empty, whitespace and marker strings; five are distinct. Outputs in these examples show selected report fields rather than every field.

Separate identical records from repeated IDs

{
  "input": "id,value\nA,x\nA,x\nA,y\nB,\nB\nC,",
  "options": {
    "delimiter": ",",
    "header": true,
    "nullMarkers": [],
    "keys": [
      0
    ],
    "numericColumns": [],
    "dateFormat": "YYYY-MM-DD",
    "constraints": [],
    "includeExamples": false
  }
}

{
  "summary": {
    "rows": 6,
    "missing": 1,
    "empty": 2
  },
  "duplicates": {
    "records": {
      "groups": 1,
      "duplicateRows": 1,
      "participatingRows": 2,
      "examples": [
        {
          "row": 2,
          "previousRow": 1
        }
      ]
    },
    "keys": {
      "groups": 2,
      "duplicateRows": 3,
      "participatingRows": 5,
      "examples": [
        {
          "row": 2,
          "previousRow": 1
        },
        {
          "row": 3,
          "previousRow": 1
        },
        {
          "row": 5,
          "previousRow": 4
        }
      ]
    }
  }
}

Rows 1 and 2 are identical; row 3 shares their A key but has a different value. Both B rows share a key, although an empty value and an absent field make them different complete records. Three extra key copies occur across two groups involving five rows. No row is deleted.

Compare composite strings without concatenation collisions

{
  "input": "region,id\nnorth,001\nnorth,1\nsouth,001\nnorth,001\nnorth\nnorth,\na|b,c\na,b|c",
  "options": {
    "delimiter": ",",
    "header": true,
    "nullMarkers": [],
    "keys": [
      0,
      1
    ],
    "numericColumns": [],
    "dateFormat": "YYYY-MM-DD",
    "constraints": [],
    "includeExamples": false
  }
}

{
  "summary": {
    "rows": 8,
    "missing": 1,
    "empty": 1
  },
  "duplicates": {
    "keys": {
      "groups": 1,
      "duplicateRows": 1,
      "participatingRows": 2,
      "examples": [
        {
          "row": 4,
          "previousRow": 1
        }
      ]
    }
  }
}

Only row 4 repeats the complete north + 001 key from row 1. 001 differs from 1, and an absent id differs from an empty id. The tuples [a|b, c] and [a, b|c] are separate keys even though naïve vertical-bar concatenation would make them look alike. Request column indexes are zero-based; diagnostic data-row numbers start at 1.

Preserve leading zeros and adjacent long IDs

{
  "input": "code\n001\n1\n9007199254740992\n9007199254740993\n001",
  "options": {
    "delimiter": ",",
    "header": true,
    "nullMarkers": [],
    "keys": [],
    "numericColumns": [
      0
    ],
    "dateFormat": "YYYY-MM-DD",
    "constraints": [
      {
        "column": 0,
        "required": false,
        "unique": true,
        "type": "any"
      }
    ],
    "includeExamples": false
  }
}

{
  "columns": [
    {
      "index": 0,
      "present": 5,
      "unique": 4,
      "duplicateValues": 1,
      "types": {
        "number": 1,
        "date": 0,
        "boolean": 0,
        "identifier": 4,
        "text": 0
      },
      "inferred": "mixed",
      "conflicts": 1,
      "numeric": {
        "accepted": 1,
        "excluded": 4,
        "min": "1",
        "max": "1",
        "sum": "1",
        "mean": 1,
        "meanApproximate": true
      }
    }
  ],
  "summary": {
    "constraintViolations": 1
  },
  "duplicates": {
    "records": {
      "groups": 1,
      "duplicateRows": 1,
      "participatingRows": 2
    }
  }
}

The two long IDs remain different strings, and 001 is not converted to 1. Only the canonical quantity 1 is eligible for numeric statistics. The column is mixed, with four identifier-shaped cells and one numeric cell. The explicit uniqueness rule flags only the second 001, not either long ID.

Count numeric exclusions and keep decimal sums exact

{
  "input": "amount\n0.1\n0.2\n0.3\n001\n9007199254740992\n1e3\n+2\n 2 \nInfinity\n0.1234567\n\"\"",
  "options": {
    "delimiter": ",",
    "header": true,
    "nullMarkers": [],
    "keys": [],
    "numericColumns": [
      0
    ],
    "dateFormat": "YYYY-MM-DD",
    "constraints": [],
    "includeExamples": false
  }
}

{
  "summary": {
    "rows": 11,
    "empty": 1
  },
  "columns": [
    {
      "index": 0,
      "numeric": {
        "accepted": 3,
        "excluded": 7,
        "min": "0.1",
        "max": "0.3",
        "sum": "0.6",
        "mean": 0.19999999999999998,
        "meanApproximate": true
      }
    }
  ]
}

Only 0.1, 0.2 and 0.3 are accepted: their exact decimal sum is the string 0.6. Seven populated values are excluded because they are identifiers, exponent/plus/space forms, nonfinite text or exceed six fractional digits. The empty cell is a missing-value category, not a numeric exclusion. Mean is explicitly approximate; a last-bit floating-point artifact does not alter the exact sum.

Separate impossible dates from the broader date rule

{
  "input": "date\n29/02/2024\n29/02/2023\n31/04/2024\n01/02/2024\n\"\"\n1/2/2024\nN/A",
  "options": {
    "delimiter": ",",
    "header": true,
    "nullMarkers": [
      "N/A"
    ],
    "keys": [],
    "numericColumns": [],
    "dateFormat": "DD/MM/YYYY",
    "constraints": [
      {
        "column": 0,
        "required": false,
        "unique": false,
        "type": "date"
      }
    ],
    "includeExamples": false
  }
}

{
  "summary": {
    "rows": 7,
    "empty": 1,
    "nullMarker": 1,
    "invalidDates": 2,
    "constraintViolations": 3
  },
  "columns": [
    {
      "index": 0,
      "types": {
        "number": 0,
        "date": 2,
        "boolean": 0,
        "identifier": 0,
        "text": 3
      },
      "invalidDates": 2
    }
  ]
}

The 2024 leap day and 1 February are valid DD/MM/YYYY dates. The 2023 leap day and 31 April match the chosen shape but fail the calendar, giving two invalid-date findings. The date type rule also rejects non-padded 1/2/2024, for three rule violations in total. Empty and configured N/A are skipped because this rule is not required.

Choose month-first meaning explicitly

{
  "input": "date\n01/02/2024\n12/31/2024\n31/12/2024",
  "options": {
    "delimiter": ",",
    "header": true,
    "nullMarkers": [],
    "keys": [],
    "numericColumns": [],
    "dateFormat": "MM/DD/YYYY",
    "constraints": [
      {
        "column": 0,
        "required": false,
        "unique": false,
        "type": "date"
      }
    ],
    "includeExamples": false
  }
}

{
  "summary": {
    "invalidDates": 1,
    "constraintViolations": 1
  },
  "columns": [
    {
      "index": 0,
      "types": {
        "number": 0,
        "date": 2,
        "boolean": 0,
        "identifier": 0,
        "text": 1
      },
      "inferred": "mixed"
    }
  ]
}

MM/DD/YYYY makes 01/02/2024 mean January 2 and accepts 12/31/2024. It rejects 31/12/2024 because month 31 cannot exist. Selecting DD/MM/YYYY would change the interpretation of the first string. The report classifies the strings but never rewrites them.

Apply required, uniqueness and type rules deliberately

{
  "input": "id,amount,flag\nA,10,true\nA,x,TRUE\n,20,false\nB,,false\nC,30,yes",
  "options": {
    "delimiter": ",",
    "header": true,
    "nullMarkers": [],
    "keys": [],
    "numericColumns": [],
    "dateFormat": "YYYY-MM-DD",
    "constraints": [
      {
        "column": 0,
        "required": true,
        "unique": true,
        "type": "any"
      },
      {
        "column": 1,
        "required": true,
        "unique": false,
        "type": "number"
      },
      {
        "column": 2,
        "required": false,
        "unique": false,
        "type": "boolean"
      }
    ],
    "includeExamples": false
  }
}

{
  "summary": {
    "rows": 5,
    "empty": 2,
    "constraintViolations": 6,
    "typeConflicts": 3
  },
  "columns": [
    {
      "index": 0,
      "inferred": "text"
    },
    {
      "index": 1,
      "inferred": "mixed",
      "conflicts": 1
    },
    {
      "index": 2,
      "inferred": "mixed",
      "conflicts": 2
    }
  ]
}

There are six explicit rule violations: repeated A, missing id, nonnumeric x, missing amount, and the nonboolean strings TRUE and yes. Only lowercase true and false count as booleans. The three heuristic type conflicts are separate from the six rule violations, so these counts must not be added as distinct bad cells.

Diagnose names without rewriting them

{
  "input": ", id ,id\nA,B\nC,D,E,F",
  "options": {
    "delimiter": ",",
    "header": true,
    "nullMarkers": [],
    "keys": [],
    "numericColumns": [],
    "dateFormat": "YYYY-MM-DD",
    "constraints": [],
    "includeExamples": false
  }
}

{
  "summary": {
    "rows": 2,
    "columns": 4,
    "expectedColumns": 3,
    "cells": 6,
    "raggedRows": 2,
    "headerIssues": 2,
    "missing": 2,
    "structuralValid": false
  },
  "columns": [
    {
      "index": 0,
      "name": ""
    },
    {
      "index": 1,
      "name": " id "
    },
    {
      "index": 2,
      "name": "id"
    },
    {
      "index": 3,
      "name": "column4"
    }
  ],
  "issues": [
    {
      "code": "emptyHeader",
      "row": 0,
      "column": 1
    },
    {
      "code": "duplicateHeader",
      "row": 0,
      "column": 3,
      "expected": 2
    },
    {
      "code": "ragged",
      "row": 1,
      "expected": 3,
      "actual": 2
    },
    {
      "code": "ragged",
      "row": 2,
      "expected": 3,
      "actual": 4
    }
  ]
}

The blank first header is flagged. Header duplicate detection compares trimmed names, so id repeats the earlier spaced name, but the displayed names stay unchanged. The header expects three fields; both two-field and four-field records are ragged. Profiling includes the fourth positional column, so the short first row has two absent cells. Header diagnostics use row 0.

Profile headerless TSV with quoted multiline cells

{
  "input": "001\t\"first\nline\"\n002\t\"say \"\"yes\"\"\"\n001\t\"first\nline\"",
  "options": {
    "delimiter": "\t",
    "header": false,
    "nullMarkers": [],
    "keys": [
      0
    ],
    "numericColumns": [],
    "dateFormat": "YYYY-MM-DD",
    "constraints": [],
    "includeExamples": true
  }
}

{
  "summary": {
    "rows": 3,
    "columns": 2,
    "cells": 6,
    "structuralValid": true
  },
  "columns": [
    {
      "index": 0,
      "name": "column1",
      "inferred": "identifier"
    },
    {
      "index": 1,
      "name": "column2",
      "examples": [
        {
          "row": 1,
          "value": "first\nline",
          "truncated": false
        },
        {
          "row": 2,
          "value": "say \"yes\"",
          "truncated": false
        },
        {
          "row": 3,
          "value": "first\nline",
          "truncated": false
        }
      ]
    }
  ],
  "duplicates": {
    "records": {
      "groups": 1,
      "duplicateRows": 1,
      "participatingRows": 2
    },
    "keys": {
      "groups": 1,
      "duplicateRows": 1,
      "participatingRows": 2
    }
  }
}

Tab is selected and the first record is data. The quoted line break stays inside one field; doubled quotes become literal quotes. There are three data records, regardless of physical line count. Generated column1 and column2 identify positions, and enabling examples deliberately exposes the original parsed cell text.

Leave cell examples out of the default report

{
  "input": "id,note\n001,=1+1\n002,<script>alert(1)</script>",
  "options": {
    "delimiter": ",",
    "header": true,
    "nullMarkers": [],
    "keys": [],
    "numericColumns": [],
    "dateFormat": "YYYY-MM-DD",
    "constraints": [],
    "includeExamples": false
  }
}

{
  "exact": true,
  "examplesIncluded": false,
  "columns": [
    {
      "index": 0,
      "examples": []
    },
    {
      "index": 1,
      "examples": []
    }
  ],
  "issues": []
}

Both column example lists are empty by default. Formula-like and HTML-like cell strings are analyzed as text; no formula or script runs. Headers and configuration still appear in the report, so this setting does not anonymize the dataset. The full original rows are not an export format of this profiler.

Opt into capped examples without calling them redacted

{
  "input": "=header\n=1+1\n<img src=x onerror=alert(1)>\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\nlast value",
  "options": {
    "delimiter": ",",
    "header": true,
    "nullMarkers": [],
    "keys": [],
    "numericColumns": [],
    "dateFormat": "YYYY-MM-DD",
    "constraints": [],
    "includeExamples": true
  }
}

{
  "examplesIncluded": true,
  "columns": [
    {
      "index": 0,
      "name": "=header",
      "examples": [
        {
          "row": 1,
          "value": "=1+1",
          "truncated": false
        },
        {
          "row": 2,
          "value": "<img src=x onerror=alert(1)>",
          "truncated": false
        },
        {
          "row": 3,
          "value": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx…",
          "truncated": true
        }
      ]
    }
  ]
}

Only the first three populated examples appear; the third string is shortened to 80 UTF-16 code units plus an ellipsis. The fourth value is not listed, but still contributes to counts. Text is rendered safely. A protected CSV export adds apostrophe protection to the formula-like header and example; JSON keeps their strings. Neither clipping nor formula protection removes private content.

Stop instead of profiling malformed quoting

{
  "input": "id,note\n1,\"unfinished",
  "options": {
    "delimiter": ",",
    "header": true,
    "nullMarkers": [],
    "keys": [],
    "numericColumns": [],
    "dateFormat": "YYYY-MM-DD",
    "constraints": [],
    "includeExamples": false
  }
}

{
  "error": "syntax"
}

An opening quote never closes, so the parser returns syntax and no quality report is available. Fix the source quoting rather than treating this as an empty or successful dataset. Parser record coordinates include the header; normal report data-row coordinates exclude it.

Recognize that header-only input contains no observations

{
  "input": "id,amount",
  "options": {
    "delimiter": ",",
    "header": true,
    "nullMarkers": [],
    "keys": [],
    "numericColumns": [
      1
    ],
    "dateFormat": "YYYY-MM-DD",
    "constraints": [],
    "includeExamples": false
  }
}

{
  "summary": {
    "rows": 0,
    "columns": 2,
    "cells": 0,
    "structuralValid": true
  },
  "columns": [
    {
      "index": 0,
      "inferred": "none",
      "unique": 0
    },
    {
      "index": 1,
      "inferred": "none",
      "unique": 0,
      "numeric": {
        "accepted": 0,
        "excluded": 0,
        "min": null,
        "max": null,
        "sum": "0",
        "mean": null,
        "meanApproximate": true
      }
    }
  ]
}

A valid header is not evidence of populated data. Both columns have no inferred type or distinct values. For the selected numeric column, zero accepted values gives null minimum, maximum and mean; the sum is the string 0. This is not a zero-valued measurement or a guarantee of complete data.

Common data-quality review mistakes

Accepting a profile produced with the wrong delimiter or header setting.
Treating absent, empty, whitespace-only and literal null-marker text as one interchangeable value.
Choosing only order_id when multiple order lines legitimately share it.
Interpreting leading-zero IDs or large account numbers as quantities because they contain digits.
Assuming a likely type validates a business rule, or that a numeric average includes every nonempty cell.
Guessing an ambiguous date format, or expecting invalid dates to be automatically repaired.
Enabling examples and then sharing the report as though bounded or shortened values were anonymous.

Limits and notes

Comma, tab, semicolon and vertical bar are explicit delimiters, not automatic detection. Files support UTF-8, UTF-16 LE or UTF-16 BE with matching optional BOMs. Quoted delimiters, doubled quotes and multiline cells are parsed; malformed quoting or invalid decoding blocks analysis instead of producing a misleading partial profile. Blank or duplicate headers and unequal row lengths are diagnosed. Header diagnostics compare trimmed names, while displayed names and cell values remain unchanged. Columns use numeric positions so repeated names are not silently collapsed. Headerless data uses generated positional labels. Reported data-row numbers exclude a header, and header issues use row 0. Parser record numbers include a header and can differ from physical line numbers.
An absent trailing field, an existing empty string, a whitespace-only string and an exact configured null marker are different states. Whitespace classification uses ECMAScript trim() whitespace without modifying the stored value. A literal null or N/A is ordinary text until you configure that exact marker. Missingness is descriptive, not a schema requirement: an optional blank field can be acceptable. Distinct values and duplicate checks use exact parsed strings, so 001 differs from 1, A differs from a and a space differs from empty. A missing key component differs from an empty one. Composite keys use separate components rather than separator concatenation; repeated-key findings do not establish which record is correct. Distinct counts include every present string, including empty, whitespace and marker text, but exclude absent cells. The extra duplicate-value count is present cells minus distinct strings. Empty and whitespace categories take priority over configured markers, making the four missing categories mutually exclusive.
Likely types and conflicts are heuristics, not an authoritative schema or business validation. A column with multiple observed types is mixed; conflicts count nonmissing cells outside the largest type group. A tie still remains mixed; located conflict examples break ties in number, date, boolean, identifier, text order, not by semantic importance. Only lowercase true and false are booleans. Zero-prefixed or 16-or-more-digit integer-like strings are treated as identifier-shaped text. No value is coerced, rewritten or evaluated. Numeric statistics are opt-in. Eligible text has an optional minus sign, canonical integer digits without leading zeros, and an optional fraction of one to six digits; it must have at most 15 significant digits and magnitude no greater than Number.MAX_SAFE_INTEGER. Leading plus, exponent forms, outer whitespace, Infinity, NaN and greater precision are excluded. Numeric exclusions count rejected nonmissing strings only. Minimum, maximum and sum are exact decimal strings; mean is explicitly approximate binary floating-point, not an exact-decimal accounting result. The selected date pattern is YYYY-MM-DD, DD/MM/YYYY, MM/DD/YYYY or YYYY/MM/DD. Valid dates need exact field widths and a real proleptic Gregorian date in years 0001–9999. No locale guessing, timestamp parsing, timezone conversion or repair is performed. Invalid-date counts flag populated strings that match the selected date shape but fail the calendar. A per-column date type rule also rejects populated strings with the wrong shape; these counts overlap and are not distinct bad cells. Required rules reject all four missing categories. Unique rules compare exact nonmissing strings and flag each occurrence after the first. Number, date and boolean rules check their defined syntax; text accepts any nonmissing string, including numeric-looking text. Type and uniqueness rules skip missing categories unless required is also selected. All constraints are explicit and the input stays unchanged.
Limits are 2 MiB of file bytes and decoded UTF-8 text, 10,000 data rows, 128 columns and 200,000 actual cells. Exact per-column distinct sets have a combined 200,000-entry budget. Reports are capped at 1 MiB. The first 500 located issues are retained with a truncation flag; full issue counts remain available. Each column lists at most three opted-in examples. Each of the retained issues may also include an example, so three per column is not an overall disclosure cap. Example excerpts use up to 80 UTF-16 code units and header excerpts up to 160, without splitting surrogate pairs; shortened text adds an ellipsis. Up to 100 configured markers of 200 code units each are accepted. Counts cover the complete accepted input, not a preview sample. Missing cells are counted across the widest observed table, while actual-cell counts exclude absent positions. Exceeding an analysis limit blocks the operation. Worker execution, cancellation and timeouts reduce load but are not a hard browser-memory sandbox; use a local data tool for larger files.
Cell-value examples are off by default. Enabling them can reveal private data in the page and exports; short or bounded examples are not anonymization. Headers, configured markers, options, positions and aggregate counts still appear without examples and can be sensitive. The report never embeds all original input rows as a table export. No input or report is uploaded or saved to browser storage by this tool. Working data stays in page/worker memory until cleared, replaced or the page is closed. Downloaded reports persist wherever you save or share them and remain outside the tool’s control. Protected CSV prefixes formula-like source text with an apostrophe, which changes the exported text. CSV quoting alone does not prevent formula injection, and protection cannot guarantee safe interpretation in every spreadsheet or after a file is saved again. JSON treats included examples as strings and does not execute them, but still contains any examples you opted into. Neither report is an import-ready repaired table, a schema contract, a business-rule audit or a guarantee that data is safe to publish.

Frequently asked questions

Why distinguish absent, empty, whitespace and null markers?

In id,value followed by a record containing only 7, the value field is absent. The record 7, contains an existing empty string; 7, contains whitespace text. The record 7,N/A contains the string N/A, counted as a marker only if you explicitly configure it. These states imply different possible source problems, and merging them would hide evidence. This profiler reports them without changing the input.

What is the difference between complete-row and key duplicates?

Complete-row duplicates require the same row length and the same exact strings in every position. Selected-key duplicates compare only the chosen positional columns as a tuple. Two rows can have the same order_id but different status values: they are duplicate keys without being identical rows. A group with three members contains three involved rows and two extra copies beyond its first member. No row is removed and no winner is selected.

Does a likely type mean every value must have that type?

No. The label summarizes observed syntax; a mixed column may be intentional. Conflicts count cells outside the largest observed type group, without an external schema. Add required, unique and explicit type rules if you know your contract. Required includes absent, empty, whitespace and marker cells; uniqueness skips those categories and compares the remaining raw strings. Numeric summaries need explicit selection. They preserve exact decimal min/max/sum within the eligibility limits, but the mean is approximate. Start with wrong delimiters, malformed quotes and unexpected headers or widths. Then check missing-value conventions and whether your selected key actually identifies one record. Enable date or numeric checks only for known columns. Use the CSV viewer and cleaner to apply explicit changes, or investigate the upstream export, and rerun this profile. There is no arbitrary score to optimize: decide which findings matter for your destination and business rules.

Can I share the report without exposing source values?

Leave value examples off. Counts and row positions remain useful, but headers, configured markers, options and aggregates are still included and can identify a sensitive dataset. Review before sharing. Turning examples on deliberately includes bounded original values; truncation is not redaction. Local processing and formula protection do not make a report anonymous.