Add a gender column to a CSV or Excel file

You have a customer list with a first-name column and you need a gender column next to it — for segmentation, for a report, for a mail merge. No code, no API keys, no waiting on an engineer.

This takes about three minutes. The part worth slowing down for is the last section, on what to do with the rows that come back empty.

Working in Google Sheets? The NameGender add-on does the same thing without leaving the sheet: select the column, run it from the sidebar, and the gender, probability, sample size, match type and matched name are written to the columns on the right. The advice below about countries and empty rows applies to it unchanged. For a file of hundreds of thousands of rows, the upload described here is still the faster route.

Before you upload

Two things to check in your file:

One name per cell. Ayşe Yılmaz, Dr. Ayşe Yılmaz and Yılmaz, Ayşe all work: titles are dropped, a comma is read as surname first, and the first name is the one looked up. Mrs A. Yılmaz will come back empty, because an initial is not a name.

A country column, if you have one. This is the single highest-leverage thing you can add. Andrea is male in Italy and female in Germany. Jean is male in France and female in the United States. Without a country the API returns the globally dominant reading, which will be wrong for a predictable slice of your list. ISO codes (TR, DE, US) or plain country names both work.

Limits: 1,000,000 rows and 100 MB per file, CSV or XLSX. That is not a marketing ceiling — a real one-million-row CSV processes in about 8.6 seconds, and the XLSX equivalent in about 34.

Uploading

Open Files in the dashboard and drop the file in.
The columns get detected automatically. Check the guess — the name column matters, and if a country column was found, confirm it is the right one.
Confirm the row count and the credit cost, which are shown before anything is charged.
Start it. Large files keep processing if you close the tab.

What comes back

Your original columns, untouched, plus ten:

Column	What it holds
`gender`	`male`, `female`, or empty when there is no evidence
`probability`	0–100. How dominant that gender is in the observed data
`sample_size`	How many observations the answer is based on
`country`	The country the answer was resolved against
`source`	`db`, `fuzzy`, or `ai` — where the answer came from
`matched_as`	The name it actually matched, if that differs from your input
`first_name`	The given name parsed from the cell
`middle_name`	Any further given names, such as `Fitzgerald` in `John Fitzgerald Kennedy`
`last_name`	The surname, including particles such as `van` or `de la`
`name_type`	`personal`, `organization` for rows like `Acme LLC`, or `role` for rows like `Customer Service`. The last two get no gender

matched_as is the one people overlook and then need. If your input was Mehmetcan and it matched as Mehmet, that is recorded, so you can audit it rather than wonder.

Reading the confidence fields

This is where a gender column becomes either useful or quietly misleading.

probability is not a confidence score in the way people assume. It is the observed share of one gender among the records for that name. Andrea at 62% female does not mean the system is 62% sure — it means that in the data, 62% of the Andreas recorded were female. That is a real property of the world, not a hedge.

sample_size is what tells you whether to trust the probability. A 100% result drawn from 40,000 observations and a 100% result drawn from three are not the same claim, and they arrive in the same-shaped cell. Sort by sample_size ascending and look at the bottom of your file — that is where the shaky rows live.

A filter that works well in practice:

Keep:   probability >= 90 AND sample_size >= 50
Review: everything else that has a gender
Drop:   gender is empty

source tells you how the answer was reached. db is a direct lookup in reference data. fuzzy means the name was matched approximately — usually a spelling variant — and deserves more scrutiny. ai is a model fallback and is off by default.

The empty rows

Some names will come back with no gender. This is deliberate: no evidence produces no answer, rather than a coin flip dressed up as a result. A confident wrong answer is worse than an empty cell, because nothing downstream can detect it.

What to do with them:

Check for a pattern first. If your empty rows are concentrated in one country, that is a data-coverage gap, and we publish where ours are — about a third of Hebrew names and half of Thai names still come back empty today. Better to know now than to conclude your list is dirty.
Look for formatting damage. Names that lost their diacritics somewhere upstream (Jose for José, Muge for Müge) match at a lower rate. Re-exporting as UTF-8 sometimes recovers a percent or two.
Leave them empty. For most segmentation work, an unknown segment is a legitimate segment. It is certainly more honest than a 50/50 guess spread across your reporting.

Two things about the data itself

Your source file is deleted as soon as processing finishes — physically removed from disk, not just marked. The result file stays until you download it, and you can delete it from the dashboard whenever you want.

Duplicates are not billed twice. Names are deduplicated before lookup, which matters more than it sounds: a 200,000-row customer list typically contains only around 16,000 unique first names. You are charged for the lookups, not the rows.

If you would rather not upload anything

The same thing is available as an API, and the free tier — 500 credits on signup plus 100 a day — is enough to check the result quality on a sample before you commit to anything:

curl "https://namegender.com/api/v1/gender?name=Ayşe&country=TR" \
  -H "Authorization: Bearer YOUR_KEY"

{
  "name": "Ayşe",
  "gender": "female",
  "probability": 100,
  "sample_size": 655,
  "country": "TR",
  "source": "db"
}

A reasonable way to start: run 200 rows you already know the answer to, and check the result against your own labels before running the other 200,000.