How do I convert a GEDCOM file to Excel?
Convert the .ged to CSV first, then open the CSV in Excel. A browser converter does it in one pass: drop the file in, pick the Excel option, and download a sheet with one row per person. Excel reads CSV natively, so you can save it as .xlsx afterwards if you want.
- Open the free GEDCOM converter.
- Drop your .ged file onto the page.
- Leave the Excel option selected and download the people sheet.
- Open the CSV in Excel, then save as .xlsx if you want to keep column widths and colours.
You get two sheets rather than one, because a family tree is not one table. The people sheet holds a row per person. The families sheet holds a row per marriage, which is where a couple's wedding date and place live in the GEDCOM format. Most questions you want to ask are answerable from the people sheet alone.
Why do accented names look wrong when Excel opens my CSV?
Excel guesses a CSV's character encoding from your regional settings instead of reading the file, so Zoé Lefèvre arrives as Zoé Lefèvre. Adding a byte-order mark to the front of the file removes the guesswork. That is the only difference between the two CSV options in our converter.
If the names are already mangled inside the .ged before you convert anything, the cause is different: older files use an encoding called ANSEL, newer ones UTF-8, and a program reading one as the other produces symbol soup. The GEDCOM validator reports which encoding your file actually declares, and our converter handles both.
- Accents broken only in Excel: pick the Excel option, which writes the byte-order mark Excel looks for.
- Accents broken in every program: an encoding problem inside the file itself. Run the validator.
- Everything in one column: your copy of Excel expects semicolons as separators, a regional setting. Import the file through Data then From Text/CSV and set the delimiter there.
What columns should a family tree spreadsheet have?
Enough to answer a research question without opening the tree again: name, sex, birth and death with places, and the immediate family. The column researchers underuse is a count of source citations per person, because sorting by it shows you which ancestors you have been taking on faith.
| Column | Why it earns its place |
|---|---|
| ID | The file's internal identifier, so you can match a row back to the .ged |
| Name, Given name, Surname | Full name for reading, split parts for sorting and filtering |
| Sex | Needed for most charts and for spotting mis-linked people |
| Birth and death date and place | The dates exactly as the file stores them, including About and Before |
| Father, Mother, Spouses, Children | Family as names, not as identifiers |
| Occupation | Often the detail that separates two people with the same name |
| Sources | How many citations back this person up. Sort ascending to find the weak spots |
Dates come through as written rather than converted to real dates. Genealogy dates are frequently not dates at all: About 1840, Before 1912, and Between 1861 and 1862 all carry meaning that a spreadsheet date column would destroy. Keep the column as text.
Why does my converted spreadsheet show @I123@ instead of names?
Because that is how GEDCOM stores relationships. A person's father is not recorded as a name but as a pointer to another record, like @I123@. A converter that dumps the file's fields straight into columns hands you the pointers, which is technically faithful and practically useless.
Resolving those pointers means following each one to the record it names and writing the name in its place. Our GEDCOM converter does that for parents, spouses and children, so the Father column reads Henry Cobb rather than @I417@. Where several children or spouses exist, they land in one cell separated by semicolons.
Is a Python or Colab script a better way to convert a GEDCOM?
For years the standard answer to this question has been a Python script or a shared Colab notebook, and those genuinely work. The trade-offs are that you need to be comfortable running code, and that using a hosted notebook means copying your family file onto someone else's machine to do it.
A browser converter avoids both. There is nothing to install and no runtime to start, and because the parsing happens in the page, the file stays on your device. Where a script still wins is a job with a custom shape: extracting one unusual tag, matching against another dataset, or converting two hundred files in a loop.
What can I do in a spreadsheet that a tree view cannot?
Ask questions across everyone at once. A tree view shows you one family at a time, which is the wrong shape for finding patterns. Sorting and filtering a flat sheet surfaces the gaps, the duplicates, and the clusters that a chart quietly hides.
- Sort by the Sources column to find every person with no citation at all.
- Filter birth places to see which parish or county the family really came from.
- Sort by surname and birth year to spot the same person entered twice under two spellings.
- Filter to deaths in one narrow window, which is how an epidemic or a mine disaster shows up in a family.
- Count people per generation to see where your research stopped rather than where the family did.
For the last one, a chart is still easier to read than a column of numbers. Drop the same file into the GEDCOM viewer and the empty branches are visible immediately.
How do I convert only part of my tree?
Pick a person and export their line instead of the whole file. Our converter takes a starting person, then whether to keep ancestors, descendants or both, and an optional generation cap, and writes that slice as its own .ged you can then convert or send on.
This is the polite answer when a cousin asks for their side of the family. Rather than handing over four thousand people, most of them strangers to them, you send the branch they asked about. It is also how you keep a spreadsheet down to a size you can actually read.
What gets lost when a GEDCOM becomes a spreadsheet?
A fair amount, because a tree is a graph and a sheet is a grid. Full source citations, note text, media file references, custom tags your software invented, and the finer structure of repeated events all flatten or fall away. Keep the .ged as your master copy.
- Someone married three times gets one Spouses cell, not three rows with three marriage dates. The families sheet holds those.
- A person with eleven separate census citations gets the number 11, not eleven citations.
- Photo and document references point at files that were never in the GEDCOM to begin with.
- Custom tags that only your tree program understands are dropped.
So treat the spreadsheet as a working view rather than a backup. If your aim is to keep researching instead of auditing, importing the same .ged into AncestorIQ keeps the structure intact and lets Deep Research go looking for the records behind the thin rows. New to the format, or handed a file you cannot open? Start with how to open a GEDCOM file. Still getting the file out of another site? See the export guides for Ancestry and MyHeritage.
