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.
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
- 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 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 (
JoseforJosé,MugeforMü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.