Column Detection

How columns are detected

The tool decides what each column contains, and that decision drives everything else. Understanding it is the difference between a useful output and a file where the sensitive column was treated as ordinary text.

The order of the guess

For each value, in this order:

1. The column header, matched by substring, case-insensitively. email, mail, url, link, web, date, time, year, month, day, phone, tel, fax, lat, long, lng, address, addr, id, identifier, code, number, serial, price, cost, amount, currency, value
2. The value itself, if the header said nothing: is it an email, a YouTube URL, a URL, a date, a number
3. Otherwise, general string

The header wins. That is a reasonable design, and it has two consequences worth knowing before you trust the output.

Substring matching over-matches

The header check is a plain substring test, so a word that happens to contain one of those fragments takes its type. Real examples:

Header	Detected as	Because
provider	id	contains id
video_title	id	contains id
width	id	contains id
residence	id	contains id
candidate	date	contains date
plate_number	latitude	contains lat

A column of number plates treated as latitudes is the memorable one, but the common case is quieter: anything typed as id gets light, length-preserving fuzzing, which is the gentlest treatment available. A column you expected to be scrambled comes back looking almost unchanged.

Non-English headers fall through

The fragments are English. A file with Italian, German or Spanish headers mostly does not match, and the columns default to general string:

Header	Detected as
nome	string
indirizzo	string
codice_fiscale	string
iban	string
ssn	string

telefono is an exception, since it contains tel, and email works in most languages.

The important line in that table is codice_fiscale, and iban and ssn alongside it. These are among the most identifying fields a file can contain, and they are treated as ordinary text, so with a preset that fuzzes rather than redacts strings, they come back as recognisable variations of the original.

What to do about it

Rename the headers before uploading. It is the simplest fix and it works with the grain of the tool: name the column email, phone, address, date, and it gets the right treatment. For a national identifier there is no matching type, so name it something that lands on a type you want, or handle it with the next point.

Redact rather than fuzz for anything sensitive, and check the preset actually enables redaction for that class. See Choosing settings.

Delete the column. If you do not need it in the output, removing it beats any amount of configuration.

Verify by reading the output. Open the result and look at the columns you care about. Values that look like near-misses of the originals are the signal that a column was fuzzed lightly when you expected it redacted.

Special handling worth knowing

• Emails are replaced with generated addresses from a small fixed list of usernames and domains, or lightly fuzzed depending on settings. The output does not resemble the input domain, which is good for privacy and bad if you were relying on the domain for grouping
• Phones are redacted outright rather than fuzzed
• URLs keep their shape while path segments are fuzzed, so a URL stays a URL. If the path itself carried an identifier, check what came out
• Numbers are perturbed within the fuzz factor, so magnitude survives. That is the point, and it is also why a salary column remains informative