Detect CSV delimiter

This detector examines a representative sample and identifies the most likely delimiter among comma, semicolon, tab, and pipe. It requires a stable pattern across non-empty lines, so it does not silently guess when the structure is inconsistent. The result includes the delimiter, its readable name, the inferred number of columns, and the number of lines examined.

Choose a representative CSV sample

Paste at least two non-empty lines from the same CSV file, ideally including the header and several ordinary data rows. A useful sample preserves the original separators and line breaks; there is no need to upload an entire large file merely to identify its format. The detector considers four common candidates: comma, semicolon, tab, and pipe. It ignores blank lines, including a final empty line left by many text editors, because those lines contain no field structure. Every meaningful line should contain the same number of occurrences of the real separator. For example, a header with three fields and two data rows with three fields produces two separator occurrences on each line. Samples containing explanatory text before the header, multiline records, or truncated rows should be cleaned or replaced with a more representative section first. Consistent input gives the tool evidence about structure instead of asking it to infer a delimiter from a single isolated character. The input stays unchanged: detection reports its finding but never reformats, parses, stores, or corrects the supplied CSV text.

Understand the frequency decision

For each candidate character, the detector counts literal occurrences on every non-empty line. A candidate remains eligible only if it appears at least once on every line and its count is identical across those lines. Among eligible candidates, the one with the greatest per-line frequency is selected. This approach is deterministic and easy to audit: the same text always produces the same result, with no model, network request, locale setting, or random choice involved. The returned column count is one greater than the winning occurrence count, while the line count shows how much evidence was examined. Frequency analysis is intentionally narrower than a complete CSV parser. In particular, candidate characters inside quoted values still count as literal occurrences. If quoted prose contains varying commas while semicolons consistently separate fields, the semicolon may still qualify correctly, but complex quoted or multiline records can make every candidate inconsistent. In that situation the detector returns an error rather than presenting an unreliable guess. Use a dedicated CSV parser after detection when you need full quote and escape handling.

Handle inconsistent and ambiguous samples

An error is useful when the sample does not support a defensible answer. If no comma, semicolon, tab, or pipe has the same positive count on every non-empty line, the tool reports that no candidate appears consistently. This commonly reveals damaged rows, mixed exports, pasted notes, or a sample that is not delimited data at all. A second error covers ambiguity: two or more candidates may appear with the same highest consistent frequency. Choosing one by arbitrary priority would make downstream parsing unpredictable, so the detector asks for a clearer sample instead. Add more representative rows, remove surrounding commentary, or inspect the source system's export settings. A one-line value is also rejected because repeated structure across lines is the core evidence used by this method. Once detection succeeds, pass the returned delimiter character into your CSV reader and optionally verify that parsed rows have the reported column count. Browser use is available without server processing, while automated API calls cost $0.002 per request. In both channels, identical pure logic produces the same result.