GEDCOM import and export¶

GEDCOM is the standard format genealogy programs use to exchange data. Almost every program — Min Släkt, Disgen, Ancestry, MyHeritage, FamilySearch — can export and import GEDCOM.

In PastPaths, you can:

Import a GEDCOM file, bringing in persons, events, places, sources, and images
Export your PastPaths data to GEDCOM so you can move it to another program or share it with relatives — and choose what stays at home, for example details about living people

Import a GEDCOM file¶

Preparation¶

Put the file where it needs to be. If the GEDCOM file comes in a zip archive together with photos — extract the whole archive to the same location. PastPaths looks for photos in the same folder and in subfolders.
Make a backup first. Imports can be undone (see below), but it's always wise to have a backup before a major change. You make one on the Import & Export page. → Backups
Don't close the program during import. Large files can take several minutes.

Carrying out the import¶

Go to Administration → Import & Export
Choose GEDCOM import
Choose your .ged file (or a .zip file with GEDCOM and images)
PastPaths tries to detect which program created the file — Ancestry, MyHeritage, TNG, PastPaths, or standard GEDCOM. The program is read from the file's header (1 SOUR). This means, for example, that Ancestry-specific tag data is brought along.
Click Start import

Once you've chosen a file, you can see how many persons and relationships will be loaded. You'll also see which program PastPaths thinks the GEDCOM file comes from.
A progress indicator shows where you are in the import. Large files (thousands of persons) can take several minutes

Large files can take a long time to import. You can see that something is happening even if it takes several minutes for large files.

Once the file has been fully imported, this is shown with a completion mark.

What gets imported?¶

PastPaths imports:

Persons with name (including nicknames and alternate names — several nicknames are saved with a semicolon between them), gender, dates of birth and death — persons marked as deceased with no known date (e.g. the GEDCOM tag DEAT Y) are correctly marked as deceased. If the person has several NAME lines, the first is the main name and the others become alternate names with the type from TYPE, for example married name or birth name. Titles (NPFX, NSFX), married names (_MARNM), aliases (_AKA, ALIA), and farm names (_FARN) also become alternate names with a type
Events — birth, baptism, believer's baptism, adoption, engagement, marriage banns, marriage, divorce, death, burial, cremation, probate, will, emigration, immigration, naturalization, census, residence, occupation, title, education, confirmation, first communion, ordination, graduation, retirement, military service, medical conditions (some programs), and custom/generic events. If an event has a description of its own (TYPE, for example "Household examination 1850" under a census), it becomes the event's title. Marriage banns (MARB) become an event of the type Marriage banns
- Baptism and believer's baptism: CHR becomes baptism and CHRA believer's baptism. BAPM is GEDCOM's ordinary baptism and becomes baptism. In files from PastPaths, and when TYPE says believer's or adult baptism, BAPM becomes believer's baptism
- Unknown events that PastPaths has no type of its own for become Other with the event's name and the tag as the title. The family's events, also census and residence under the family, get both spouses. FACT with a date, place, source, or image also becomes Other
- Details under the event: age (AGE), cause (CAUS), agency (AGNC), and religion (RELI) go into the description. RESN privacy, RESN confidential, and _PRIV make the event private
Places — with GPS coordinates if the file provides them (standard MAP/LATI/LONG under PLAC, or TNG's central place register), and tries to parse the split into city/county/country. If the file comes from PastPaths' own export, the fields are read back exactly as they were, without interpretation
Relationships — parents, partner, children, and other relations (godparent, witness), see Relationships and the couple's events
Sources with titles, references, and repository details (including contact information and call number), including an attempt to guess the source type (parish register, census, estate inventory, muster roll, etc.)
Citations with page numbers, reliability, and retrieval date
Media — images and documents if the files are included
Notes — also sources written only as text (1 SOUR <text>) and contact details (EMAIL, PHON, WWW)

Auto-tag on everything imported¶

Every record that's imported automatically gets a tag marking where it came from:

Source	Tag
Standard GEDCOM	`-gedcom-import-YYYY-MM-DD`
Ancestry	`-ancestry-import-YYYY-MM-DD`
MyHeritage	`-myheritage-import-YYYY-MM-DD`
TNG	`-tng-import-YYYY-MM-DD`
PastPaths' own export	`-pastpaths-import-YYYY-MM-DD`

The leading hyphen sorts the tag to the top of the tag list, so machine-applied tags appear before your own.

This means you can later filter persons/places/events/media by that specific tag to see exactly what came from a particular import.

If you import the same file multiple times on the same day, the same tag object is used — you won't get duplicate tag names.

Warning tag¶

Records that got a warning or an error during the import also get a red tag, so you can find the ones that need checking. The tag follows the same pattern as the import tag, for example -gedcom-warning-YYYY-MM-DD, -tng-warning-YYYY-MM-DD, and -ancestry-warning-YYYY-MM-DD.

Warning or error	Gets the tag
An image file wasn't found or couldn't be imported	The persons and events that show the image
A family couldn't be imported	The family's persons, since relationships may be missing
A TNG photo (`_PHOTO`) couldn't be imported	The person

The tag is applied even when the import fails, on the records that were saved. It's red when it's created. If you change the color, your color is kept on the next import the same day.

Relationships and the couple's events¶

A family (FAM) in GEDCOM becomes a partner relationship between the spouses. The form is decided by the family's events:

In the file	The relationship in PastPaths
`MARR` (marriage)	Married
`MARR` with `TYPE` Unmarried or Cohabiting	Cohabiting, with the event Moving in together. The type text goes into the event's description
`MARR` with `TYPE` Registered partnership	Married, with the type text as the marriage's title
Relationship status without a marriage: `_MSTAT`, `_NMR`, `_UMAR`, or `_MARR N`	The form the status gives, for example cohabiting
`_PPFORM` and `_PPEND` from PastPaths' own export	The same form and end reason as in the export
`DIV` (divorce), with or without `MARR`	Married with the end reason divorce
`ENGA` (engagement) without a marriage	Engaged
Moving in together or separation from PastPaths' own export	Cohabiting (ended on separation)
None of the above, or only `MARB` (marriage banns)	Partner

The family's events are linked to the relationship the same way as when you register them in PastPaths, and the relationship gets the events' dates. A DIV without a date also counts as a divorce. Events that don't fit the form aren't linked, and are shown in the relationship check under Maintenance.

Couples who become partner get the tag -gedcom-partner-YYYY-MM-DD (or -tng-partner-… and so on) on both persons, so you can go through them and choose the right form. Where the family has no marriage, the form is unknown.

Couples whose form came from a relationship status instead of a marriage get the tag -gedcom-relationsstatus-YYYY-MM-DD (or -tng-relationsstatus-… and so on) on both persons. Couples living together in the past were usually married, so review the form. A line such as 1 MARR Y with no further details counts for the form but gives no empty event.

Other relations in the file (ASSO with RELA) become other relations: godparent when RELA is, for example, Godparent, Godfather, Gudmor, or Fadder, witness when it's Witness or Vittne, and otherwise other with the RELA text as the note.

An adoption (ADOP) becomes an event with the child as the primary person and the adoptive parents, from the family under FAMC, with the role Parent.

Import history and undoing¶

Every import creates an entry in the Import/export history.

In the history, you can see:

When the import was done and how long it took
Which file was imported and from which source program
How many persons, places, events, media, and sources came in
Status — succeeded, failed, or undone
Any warnings and errors — click the warning button on the row to see the list

An import that was interrupted, for example because PastPaths was closed in the middle of it, is shown as failed the next time PastPaths starts.

Undo an import¶

If the import went wrong — wrong file, duplicates against existing data, or just incorrect — you can undo it. Click Undo on the relevant row in the history. This also works for an import that failed or was interrupted. Whatever was imported before the error is then removed.

Undo import — Confirm that you want to undo an import in the list.

Before you confirm, a summary is shown of what will be removed:

Persons that were imported
Events that become "orphaned" (have no remaining person linked to them)
Media (both the database row and the file on disk)
Places that become unused (no person, event, or link left to them)
Citations created by the import
Sources created by the import, but only those that haven't picked up any other citations since

What's left behind?

If you've edited anything after the import — e.g. added notes to an imported person, or linked an imported place to an event you created yourself — those links are preserved as far as possible. Places are only deleted if they become completely unused after the imported persons/events have been removed.

Global tags and categories aren't deleted

The auto-import tag (-gedcom-import-...) and the warning tag (-gedcom-warning-...) don't disappear when you undo, since other entities may share the same tag. If they become unused, you can remove them manually in the taxonomy management.

Delete a log

The trash can on the row only removes the row from the history, not what was imported — and afterward the import can't be undone. So undo first if you want to get rid of the imported data. PastPaths asks before the log is deleted.

If something goes wrong during import¶

If the program doesn't respond while a large import is running, the import dialog waits and asks again, for up to about five minutes. If the dialog gives up, it says that the import may still be running in the background. Check the import history before you import the file again, or the same data may be added twice.

If the import is interrupted or fails, it may have saved part of the data. Undo it in the import history first, or you'll get duplicates when you import again. Then try again after:

Verifying that the file isn't corrupted (open it in a text editor and check that it starts with 0 HEAD)
Closing other programs that might be locking the file
Checking that you have enough disk space

→ More troubleshooting

Export to GEDCOM¶

To move your PastPaths data to another program:

Go to Administration → Import & Export
Click Export GEDCOM file. A dialog opens, see The export dialog
Go through the choices and click Export

The export is saved as a ZIP file containing the GEDCOM file export.ged, in the export folder Documents\PastPaths\GEDCOM, with a name like pastpaths_export_20261011_143000.zip. A notification shows the exact path, with the Open folder and Copy path buttons. Extract the ZIP file and import export.ged into the other program. → More about the export folder

The export dialog¶

The dialog shows what will be included before anything is written to the file. The defaults are the safe ones, so you don't accidentally share more than you intended, and they apply from the start every time you open the dialog. Under each choice, the dialog shows how many are affected.

Private events¶

The dialog shows how many events are marked as private. The Include private events box is empty to start with:

Without the checkbox, private events are left out, along with media files that belong only to them. If the birth or death is private, the person's date and place of birth or death aren't written either. A private death is written as DEAT Y, so the person still counts as deceased. If the marriage is private, the relationship's start date isn't written as the marriage date.
With the checkbox, they're included and marked with RESN privacy, which other programs recognise.

Living persons¶

Who counts as living is decided the same way as in the rest of PastPaths: an explicit mark, otherwise a date of death, a place of death, or a death event, otherwise the 110-year rule. A person with neither a date of birth nor a date of death therefore counts as living. The dialog shows how many that applies to, and the Show in the person list button shows who they are. → Why is a person shown as living?

Choice	In the file
Include everything	Living persons are written with all details, like deceased persons
Name and family links only	Name, gender, and family links. Dates, places, events, notes, sources, and images are left out
Replace the name with "Private" (default)	As above, but the name becomes "Private"
Leave out completely	The person isn't included at all

Descendants and partners of living persons¶

A deceased person can reveal a living one: a child who died tells you who the parents were. That's why deceased children, grandchildren, and later generations of living persons who are hidden are hidden too, along with their partners. A partner who is an ancestor of a living person, for example a deceased father whose widow is alive, is above the first living person and isn't hidden.

Leave out – the tree stops at the first living person (default). The descendants and their partners aren't included.
Include anonymously as "Private". They're included with only gender and family links. Keep in mind that the relationship may still be possible to work out.

The choice doesn't apply when living persons are included in full.

Media files¶

Images and documents are included in the media folder of the ZIP file and linked to persons, events, and sources with OBJE.

Only media belonging to persons in the export (default).
All media also includes, for example, images that belong only to a place.

An image where a hidden person is tagged, or that is their profile picture, is never included, even if other persons in the image aren't hidden. The dialog shows how many of all media files are included.

Submitter¶

A GEDCOM file always has a submitter (SUBM), the person sharing the file. If you've entered your name under Administration → Settings, the Include my details as submitter box is checked. Your name, address, phone, email, and website are then written to the file, so whoever gets the file knows where it comes from. Without the checkbox, it says "PastPaths User", as before.

What the export contains¶

The export follows GEDCOM 5.5.1 and includes persons, relationships, events, sources, and media files, minus what the export dialog leaves out. The header gives the version of PastPaths that created the file. Places carry their coordinates in standard form (MAP/LATI/LONG under PLAC), so other programs can read them.

The events' own titles are written as TYPE under the event, also on birth, marriage, census, and other standard events. This is GEDCOM standard, so other programs can read the title, and PastPaths turns it back into the title on re-import. Engagement, marriage banns, marriage, and divorce are written under the family (ENGA, MARB, MARR, and DIV) when both spouses are known. If only one spouse is known, the event is written under the person, and the engagement then as a generic event (EVEN).

The relationships are exported like this:

A married couple without a marriage event gets 1 MARR Y, and a divorced couple without a divorce event 1 DIV Y — GEDCOM's way of saying that the event took place but the details are unknown.
Event types that have no tag of their own in GEDCOM, for example moving in together, separation, and visits, are written as EVEN with the type's name as TYPE. PastPaths also adds a subtag of its own (_PPTYPE) so that the type is the same on re-import. Other programs skip it.
An adoption is written as ADOP under the child, with the adoptive family under FAMC.
Other relations are written as ASSO with RELA (Godparent, Witness, or the first line of the note).
The partner form and how the relationship ended are written with PastPaths' own tags _PPFORM and _PPEND on the family, so cohabiting, engaged, living apart together, and partner stay the same on re-import. An engaged couple without an engagement event gets ENGA Y.

The names and event types are exported like this:

Alternate names are written as one NAME per name with the type as TYPE. Name prefixes and suffixes are written as NPFX and NSFX under the main name, and nicknames as one NICK per name.
Believer's baptism is written as CHRA. Cremation, probate, will, naturalization, title, ordination, and first communion are written with GEDCOM's own tags (CREM, PROB, WILL, NATU, TITL, ORDN, and FCOM).

This doesn't carry over to other programs today

Persons with other roles in an event than primary person — witness, sponsor, officiant, and similar — aren't written to the file. How best to write the roles so other programs can read them is being mapped out for a coming version. Other programs skip PastPaths' own tags (_PPTYPE, _PPFORM, and _PPEND) and see the couples as ordinary families.

On top of that, PastPaths writes its own subtags under PLAC, preserving address, city, parish, county, region, country, place type, and description separately. Other programs skip them — just as PastPaths skips Ancestry's own tags — but PastPaths recognises its own file on re-import and reads every field back exactly.

Photos and documents

The media files are in the media folder of the ZIP file, and the GEDCOM file points to them as media/filename. Extract the whole ZIP file so the other program finds them. Images that belong only to a place are only included with All media, and the GEDCOM format can't link them to the place. If you want everything, including the links to places and blog posts, make a backup instead.

Citations on places aren't carried over

The GEDCOM format has no place for a citation attached to a place. The sources themselves are included in the file, but the citations linking them to individual places are not. Citations on persons and events are exported as usual.

Specific programs¶

PastPaths has special support for GEDCOM files from:

Ancestry.com — preserves Ancestry IDs and links
MyHeritage — preserves MyHeritage IDs
TNG (The Next Generation) — imports photos, GPS coordinates, living flags

If your file comes from another program (Min Släkt, Disgen, Family Tree Maker, etc.), it's handled as standard GEDCOM.

Tips for a good import¶

Clean up the file in the original program first. It's easier to fix errors there than in PastPaths after import.
The images need to be included. The GEDCOM file only points to the images' filenames — the actual image files need to be alongside the GEDCOM file or in a subfolder. It doesn't matter how you've organized your images into subfolders — PastPaths searches all subfolders recursively, whether the GEDCOM file uses TNG's _PHOTO tag or standard OBJE/FILE entries.
Large files can take time. A file with thousands of people can take 10–15 minutes to import. Nothing dangerous — just let it finish.