People & names
The people in your tree are individual records, and most of what you’ll write about them starts with a name. These recipes go from creating a person to recording nicknames, alternate names, non-Latin spellings, and identifiers that outlast the file.
New to reading GEDCOM lines? Skim How GEDCOM works first — every recipe shows the underlying lines, but the app writes them for you as you type.
Create a person
Section titled “Create a person”The structure. A person is an INDI record. The smallest useful one is an id, a name, and a sex:
0 @I1@ INDI1 NAME Jane /Smith/1 SEX FEverything else — events, families, sources, notes — nests beneath this record.
In the app. Use Add Record (in the Edit menu, or the split button in the toolbar) and choose INDI – Person. A new tab opens with a starter record ready to fill in. For a blank record without the menu, press Ctrl+N (Cmd+Ctrl+N on macOS). To create a person and wire them into a family in one step, use Add relative instead.
Across versions. INDI records are identical in 5.5, 5.5.1, and 7.0 — only the details you put
inside them vary by version. GEDCOM 7.0 encourages every record to also carry a stable identifier; see
Give a record a stable identifier.
Validation notes. The cross-reference id (@I1@) must be unique in the file — Linea Codex assigns
one for you. A person with no NAME is technically valid (the name is optional), but every other view
keys off it, so add one.
See also: Adding relatives · Structured vs. raw modes.
Record a name and its parts
Section titled “Record a name and its parts”The structure. The NAME line holds the full name as it’s normally spoken, with the surname
between slashes. Optional name-piece tags spell the components out:
1 NAME Jane Eleanor /Smith/2 GIVN Jane Eleanor2 SURN SmithThe slashes are the only required punctuation — they tell every program which part is the surname. The
pieces (GIVN, SURN, and the rest) are optional; they just make the parts explicit for programs that
sort or search on them.
In the app. Type the NAME line in the editor; autocomplete
offers the name-piece tags when you add a line beneath it. You rarely need every piece — the slashed
NAME value alone is enough for most records.
Across versions. The NAME value and the slash convention are identical everywhere, and the piece
lines (2 GIVN …, 2 SURN …) are written the same way in 5.5, 5.5.1, and 7.0. What 5.5 lacks is the
extras covered below — a name TYPE and phonetic/romanized variants — not the basic parts.
Validation notes. The surname is delimited by a pair of slashes — that’s the convention every
program relies on to find it. Piece cardinality is version-dependent: in 5.5 and 5.5.1 each piece
tag (GIVN, SURN, …) appears at most once per name; 7.0 relaxed this, so a piece may repeat.
See also: Record nicknames, prefixes, and suffixes · The spec viewer.
Record nicknames, prefixes, and suffixes
Section titled “Record nicknames, prefixes, and suffixes”The structure. Beyond GIVN and SURN, four more pieces capture the rest of a name:
1 NAME Dr. William /Adams/ Jr.2 NPFX Dr.2 GIVN William2 SURN Adams2 NSFX Jr.2 NICK BillNPFX— name prefix (Dr., Rev., Sir)NSFX— name suffix (Jr., Sr., III)NICK— a nicknameSPFX— a surname prefix: the particle that sorts with the surname (the “van” in “van Gogh”, the “de” in “de la Cruz”)
In the app. Autocomplete offers each of these as a child of NAME.
Across versions. All six pieces — NPFX, GIVN, NICK, SPFX, SURN, NSFX — exist in every
version and are written identically.
Validation notes. In 5.5 / 5.5.1 each of these pieces appears at most once per name; 7.0
allows them to repeat. Keep a title like “Dr.” in NPFX rather than inside the slashed value if you
want it stored separately. Whether you also fold a SPFX particle into the surname slashes is your
choice.
See also: Record a name and its parts.
Record alternate names and name types
Section titled “Record alternate names and name types”The structure. A person may have several NAME lines — a maiden name, an alias, a religious
name. A TYPE says which kind each is:
1 NAME Mary /Jones/1 NAME Mary /Smith/2 TYPE maidenIn the app. Add another NAME line to the same record in the editor; autocomplete offers TYPE
beneath it and the type values valid for your file’s version.
Across versions. This is one of the most version-sensitive corners of the name structure:
- 5.5 has no name
TYPE. Record alternate names as extraNAMElines, but you can’t label them. (Converting down to 5.5 drops theTYPEline — best-effort.) - 5.5.1 added
TYPEwith the valuesaka,birth,immigrant,maiden,married, or a free-text value — written in lowercase. - 7.0 makes
TYPEan enumeration in uppercase:AKA,BIRTH,IMMIGRANT,MAIDEN,MARRIED,PROFESSIONAL, orOTHER(with aPHRASEdescribing the “other” case).
Don’t confuse this with ALIA. A second NAME line is another name on the same record; ALIA
(1 ALIA @I2@) is a pointer to a separate individual record you believe is the same person. Use
extra NAME lines for alternate spellings; use ALIA when you have two records to tie together.
Validation notes. A name TYPE in a 5.5 file is flagged (the tag isn’t valid there). In 7.0, a
TYPE OTHER should carry a PHRASE, and only the listed enum values are accepted; 5.5.1 also allows a
free-text type.
See also: Relationships (families and same-person links).
Record a person’s sex
Section titled “Record a person’s sex”The structure. One SEX line, with a single-letter code:
1 SEX FIn the app. Add a SEX line; autocomplete offers exactly the values valid for your file’s version.
Across versions. The permitted values grow with each version:
- 5.5 —
M(male) orF(female). - 5.5.1 — adds
U(undetermined). - 7.0 — adds
X(does not fit the M/F binary), and keepsU(unknown).
So 1 SEX X is valid only in 7.0; converting a file that uses a value an older version lacks will flag
it — best-effort, since there’s no exact equivalent.
Validation notes. SEX is optional and appears at most once per person. A value outside the
version’s set — X in a 5.5.1 file, say — is flagged as an invalid enumerated value. Anything beyond
the coded value belongs in a note or a custom tag.
See also: Create a person.
Record phonetic and romanized name variants
Section titled “Record phonetic and romanized name variants”Goal. Record how a name sounds, or how a non-Latin name is written in Latin letters — for example a Japanese name and its romanization.
The structure (5.5.1). ROMN holds a romanized form and FONE a phonetic one; each needs a TYPE
naming the method:
1 NAME 山田 /太郎/2 ROMN Yamada /Tarō/3 TYPE romajiROMN types include pinyin, romaji, wadegiles (or your own); FONE types include hangul,
kana (or your own).
The structure (7.0). Version 7.0 replaces FONE/ROMN with a single TRAN (translation), each
carrying a required LANG (a language tag):
1 NAME 山田 /太郎/2 TRAN Yamada /Tarō/3 LANG ja-LatnIn the app. Autocomplete is version-aware: it offers FONE/ROMN in a 5.5.1 file and TRAN/LANG
in a 7.0 file, so you’re always shown the right tags.
Across versions.
- 5.5 has no phonetic or romanized variants at all — record them in a note if you need them.
- 5.5.1 has
FONE(phonetic) andROMN(romanized), each with a requiredTYPE. - 7.0 uses one
TRANmechanism with a requiredLANGfor both. Converting between 5.5.1 and 7.0 mapsFONE/ROMN↔TRANas faithfully as it can — best-effort.
Validation notes. In 5.5.1, each FONE/ROMN requires its TYPE; in 7.0, each TRAN requires its
LANG. These are version-specific tags — FONE/ROMN in a 7.0 file, or TRAN in a 5.5.1 file, are
flagged.
See also: How GEDCOM works (non-Latin text needs a UTF-8 file).
Give a record a stable identifier
Section titled “Give a record a stable identifier”Goal. Attach an id that survives across programs and edits. The @I1@ cross-reference is not
that — it’s local to the file and can be renumbered.
The structure. REFN records your own reference number (with an optional TYPE). GEDCOM 7.0 adds
UID and EXID for globally-stable ids:
1 REFN 1842-03172 TYPE researcher-id1 UID 26d3eb01-5c4f-4d8a-9a1f-2b9c0f3a77e11 EXID 40551202 TYPE https://example.com/tree/personAcross versions.
REFN(a user reference number, with an optionalTYPE) exists in all versions.UID(a globally-unique id, typically a UUID) andEXID(an id from an external system, qualified by aTYPEURI) are 7.0 additions. In 5.5 / 5.5.1, the common practice is the custom tag_UID— see When GEDCOM has no tag for it.
Validation notes. An EXID should carry a TYPE — an EXID without one is deprecated in 7.0.
UID / EXID in a 5.5 / 5.5.1 file are flagged; use _UID there. Because the @I1@ xref is not
stable — the Renumber Cross-References command rewrites them across the whole file, and
version conversion renumbers too — reach for REFN or UID when an id must
persist.
See also: When GEDCOM has no tag for it · Converting GEDCOM versions.
Next: record the events of a life — Events & facts →.