Continue → Overview
← All notes

Add a gender column to a CSV or Excel file

5 min read guide batch

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.

Before you upload

Two things to check in your file:

One name per cell. If your column holds Ayşe Yılmaz, that is fine — the first name gets extracted. If it holds Yılmaz, Ayşe or Mrs A. Yılmaz, clean it first; a title or an initial is not a name and will lower your match rate for no reason.

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

  1. Open Files in the dashboard and drop the file in.
  2. 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.
  3. Confirm the row count and the credit cost, which are shown before anything is charged.
  4. Start it. Large files keep processing if you close the tab.

What comes back

Your original columns, untouched, plus six:

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
total_names 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

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.

total_names 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 total_names 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 total_names >= 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 — Hebrew returns nothing at all today, and Thai returns almost nothing. 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?name=Ayşe&country=TR" \
  -H "Authorization: Bearer YOUR_KEY"
{
  "name": "Ayşe",
  "gender": "female",
  "probability": 100,
  "total_names": 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.

Every claim on this page is measurable against your own list. The free tier is enough to check it.