Skip to content

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.

The structure. A person is an INDI record. The smallest useful one is an id, a name, and a sex:

0 @I1@ INDI
1 NAME Jane /Smith/
1 SEX F

Everything 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.

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 Eleanor
2 SURN Smith

The 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.

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 William
2 SURN Adams
2 NSFX Jr.
2 NICK Bill
  • NPFX — name prefix (Dr., Rev., Sir)
  • NSFX — name suffix (Jr., Sr., III)
  • NICK — a nickname
  • SPFX — 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.

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 maiden

In 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 extra NAME lines, but you can’t label them. (Converting down to 5.5 drops the TYPE line — best-effort.)
  • 5.5.1 added TYPE with the values aka, birth, immigrant, maiden, married, or a free-text value — written in lowercase.
  • 7.0 makes TYPE an enumeration in uppercase: AKA, BIRTH, IMMIGRANT, MAIDEN, MARRIED, PROFESSIONAL, or OTHER (with a PHRASE describing 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).

The structure. One SEX line, with a single-letter code:

1 SEX F

In 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.5M (male) or F (female).
  • 5.5.1 — adds U (undetermined).
  • 7.0 — adds X (does not fit the M/F binary), and keeps U (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 romaji

ROMN 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-Latn

In 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) and ROMN (romanized), each with a required TYPE.
  • 7.0 uses one TRAN mechanism with a required LANG for both. Converting between 5.5.1 and 7.0 maps FONE/ROMNTRAN as 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).

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-0317
2 TYPE researcher-id
1 UID 26d3eb01-5c4f-4d8a-9a1f-2b9c0f3a77e1
1 EXID 4055120
2 TYPE https://example.com/tree/person

Across versions.

  • REFN (a user reference number, with an optional TYPE) exists in all versions.
  • UID (a globally-unique id, typically a UUID) and EXID (an id from an external system, qualified by a TYPE URI) 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 →.