Classify data fields as PII

It recognizes common signals such as email, passport, date of birth, postal code, device identifier, and ordinary business metrics. Results include a short reason for every decision and category totals, making the output useful for an initial privacy inventory, a schema review, or a repeatable check in a data pipeline. Because it examines names rather than stored values, it is fast and deterministic, but its findings should be confirmed against the meaning and contents of the real dataset.

Start a privacy inventory from the schema

A field list is often the quickest available map of a dataset. Submit the canonical names exactly as they appear in a database, event definition, spreadsheet header, or API contract. The classifier normalizes common styles such as snake case, kebab case, spaces, and camel case before comparing each name with a curated set of signals. Names that indicate an email address, telephone number, full name, government identifier, bank account, payment card, precise address, IP address, or biometric identifier are marked as likely direct PII. These fields can commonly point to a person without needing many additional attributes. The response preserves the original field spelling, gives the classification, and explains the naming signal that produced it. This makes the result easy to join back to a schema export or place in a review worksheet. Submit only field names, not sample records or personal values. An empty list is rejected because it cannot produce a meaningful inventory, and every list item must be a non-empty string.

Interpret indirect PII in context

Indirect PII does not always identify someone on its own, yet it can narrow a population or link activity to a stable person when combined with other fields. The classifier treats names associated with birth date, age, gender, broad location, postal area, device or cookie identifiers, account handles, employment details, and similar attributes as likely indirect PII. That category is intentionally a prompt for contextual review rather than a legal conclusion. A postal code in a national statistics table has a different risk profile from the same field beside a date of birth and an employee identifier. Likewise, a customer identifier may be pseudonymous inside one system while a lookup table makes it directly attributable elsewhere. Review indirect results alongside access controls, join keys, retention periods, population size, and the availability of external datasets. The deterministic rules make repeated scans comparable across schema versions, but they cannot see undocumented semantics or determine whether combinations create singling-out risk.

Use the output as a screening signal, not proof

Names that match no recognized signal are returned as non-PII, which means only that the name itself does not reveal a common privacy cue. A vague field such as value, payload, note, answer, or data could still contain personal information. Conversely, a field named customer_email might contain a test token rather than a real address. Follow the classification with data profiling, documentation review, and input from the people who own the system. In automation, store the result beside the schema version, flag new direct or indirect fields for review, and compare category totals during change control. The output is particularly useful as a lightweight checkpoint before sharing extracts, creating analytics events, or approving a new integration. It should not replace a data protection impact assessment, counsel, or jurisdiction-specific policy. The algorithm uses no network, model, randomness, or current time, so identical input produces identical output. A request through the API costs $0.002, and the returned reasons make rule-driven decisions straightforward to audit.