Notes

Notes are GEDCOM’s catch-all for free text: research observations, reasoning, context, anything that doesn’t fit a structured tag. These recipes go from a one-line note on a record, through long and multi-line text, to notes that several records share, and finish with the language and formatting a 7.0 note can carry.

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.

Add a note to a record

The structure. A NOTE line carries free text and nests under whatever it annotates — a record, an event, a name, almost anything:

0 @I1@ INDI
1 NAME Jane /Smith/
1 NOTE Family lore says she emigrated after the 1849 famine.

This is an inline note: the text lives right there on the record. It belongs to that one record and is edited in that one place.

In the app. Type a NOTE line beneath the structure you want to annotate; autocomplete offers NOTE wherever a note is valid. The inspector gathers everything attached to the selected record into a Notes panel — it labels each one Inline note or NOTE (a referenced note record), shows a breakdown like “2 records · 1 inline”, and lets you Show full note or Open record to jump to a shared note’s own record. To add a fresh top-level note record, use Add Record → NOTE – Note.

Across versions. Inline NOTE works the same way in 5.5, 5.5.1, and 7.0 — a NOTE line with text, nested under its subject. The grammar of long notes and the shared form differ by version (the next two recipes), but a short inline note is identical everywhere.

Validation notes. A note can sit almost anywhere, so it’s rarely flagged for placement. The text is free-form — there’s no enumerated value to get wrong. The spec viewer’s entry for NOTE lists exactly which structures may carry one in your file’s version if you want to confirm a position.

Write multi-line and long notes

The structure. Each GEDCOM value lives on one line, so longer text is built from continuation tags. CONT adds a line break — the value continues on a new line:

1 NOTE Marriage performed at sea
2 CONT aboard the SS Republic, July 1851.

In 5.5 and 5.5.1 there’s a second tag, CONC, which continues a value without a break. It exists because those versions cap a line at 255 characters, so a single long paragraph must be split:

1 NOTE This is a very long research note that exceeds the line limit and so
2 CONC  is split across two physical lines using CONC, with no break between them.

The structure (7.0). Version 7.0 removed CONC and the 255-character line limit. A note uses only CONT, and each CONT is always a real line break:

1 NOTE A first paragraph of the note.
2 CONT
2 CONT A second paragraph after a blank line.

In the app. You rarely type CONC or CONT by hand. Type or paste multi-line text into a NOTE value and the editor splits it into the right continuation lines for your file’s version — CONC splitting plus CONT breaks in 5.5/5.5.1, CONT-only in 7.0. The app’s continuation handling is version-aware for exactly this reason; the mechanics are spelled out in How GEDCOM works → Long text.

Across versions.

5.5 / 5.5.1 — CONT for breaks, CONC for splitting a line that would exceed 255 characters.
7.0 — CONT only; CONC and the line-length limit are gone.

Converting down to 5.5/5.5.1 re-introduces CONC and re-wraps text to the 255-character limit; converting up to 7.0 folds CONC back into continuous text and keeps the CONT breaks. This rewriting is faithful — the text you see is unchanged — and is one of the few places where conversion is genuinely lossless, because both forms describe the same string. See Converting GEDCOM versions.

Validation notes. A stray CONC in a 7.0 file is flagged — the tag isn’t valid there. Watch the leading/trailing spaces around a CONC split: GEDCOM joins the pieces with no space, so a word broken across a CONC boundary must keep its space on one side or the two halves run together. Because the editor does the splitting, you don’t normally have to manage this, but it matters if you paste hand-split text.

Create a shared note many records can reference

Goal. Write a note once and have several records point at it, so editing it in one place updates it everywhere — for example a standard explanation of a source’s reliability, attached to many citations.

The structure (5.5 / 5.5.1). The text lives in a top-level note record (0 @N1@ NOTE …), and each user references it with a NOTE line whose value is a pointer instead of text:

0 @N1@ NOTE Transcribed from the original parish register; spelling modernised.
0 @I1@ INDI
1 NAME Jane /Smith/
1 NOTE @N1@
0 @I2@ INDI
1 NAME John /Smith/
1 NOTE @N1@

Both individuals carry 1 NOTE @N1@ — the same note, referenced twice.

The structure (7.0). Version 7.0 splits the two roles into different tags. The shared record is a shared-note record (0 @N1@ SNOTE …), and records reference it with SNOTE (the pointer), keeping plain NOTE for inline text only:

0 @N1@ SNOTE Transcribed from the original parish register; spelling modernised.
0 @I1@ INDI
1 NAME Jane /Smith/
1 SNOTE @N1@
0 @I2@ INDI
1 NAME John /Smith/
1 SNOTE @N1@

So in 7.0, NOTE always means inline text and SNOTE always means a pointer to a shared note — no more overloading one tag for both. Inline NOTE still exists in 7.0 alongside SNOTE; pick SNOTE only when editing the note once should change it everywhere.

In the app. Create the note record with Add Record → NOTE – Note, then reference it from each record’s NOTE/SNOTE line; autocomplete offers the pointer form where it’s valid and proposes existing note records as xref targets. In the inspector Notes panel, a shared note shows as a NOTE (record) entry with an Open record action, distinct from inline notes; the breakdown count tells you how many of each kind a record carries. ⌘/Ctrl-click the pointer to jump to the note’s record.

Across versions.

5.5 / 5.5.1 — one tag, NOTE, in two grammars: 0 @N1@ NOTE <text> defines the shared record, 1 NOTE @N1@ points at it.
7.0 — two tags: SNOTE for the shared record (0 @N1@ SNOTE <text>) and the pointer to it (1 SNOTE @N1@); plain inline NOTE is reserved for non-shared text.

Converting a 5.5/5.5.1 shared NOTE record up to 7.0 turns it into an SNOTE record and rewrites each pointer NOTE @N1@ to SNOTE @N1@, preserving the sharing. Converting down from 7.0 is not symmetric: the converter copies the shared note’s text inline into each referencing record and drops the standalone SNOTE record — best-effort, so the one shared copy becomes several independent ones.

Validation notes. The pointer must resolve: a NOTE @N1@ (or SNOTE @N1@) whose target record doesn’t exist is flagged as a broken reference. In a 7.0 file, using NOTE @N1@ as a pointer — or SNOTE at all in a 5.5/5.5.1 file — is flagged, because each version splits the tags differently. If you only ever reference the note from one place and don’t need to edit it in many at once, the spec recommends a plain inline note instead of a shared one.

Record a note’s language and formatting

Goal. Say what language a note is written in, and whether its text is plain or contains HTML formatting — and optionally attach translations of the note.

The structure (7.0). A 7.0 note may carry LANG (a language tag) and MIME (a media type), plus TRAN lines holding translations, each with its own LANG/MIME:

1 NOTE Named after Arete from <i>The Odyssey</i>
2 LANG en
2 MIME text/html
2 TRAN Named after Arete from "The Odyssey"
3 MIME text/plain
2 TRAN Nombrada en honor a Arete de <i>La Odisea</i>
3 LANG es

The two standard MIME values are text/plain (shown exactly as written) and text/html (a small subset of HTML for bold, italic, paragraphs, and the like). A TRAN that omits LANG or MIME inherits it from the note above it — but each TRAN must specify at least one of the two.

In the app. In a 7.0 file, autocomplete offers LANG, MIME, and TRAN as children of a NOTE, and proposes the standard media types and language tags. The spec viewer shows the full valid shape of the note structure — useful for confirming, for instance, that each translation needs its own LANG or MIME.

Across versions.

5.5 / 5.5.1 — a note has no per-note LANG and no MIME. (These versions do have a LANG, but only at the file header for the whole transmission, and a submitter language preference — neither describes an individual note.) The text is taken as plain, in the file’s overall language.
7.0 — adds LANG, MIME, and TRAN to the note structure, so each note can declare its own language, mark itself as plain or HTML, and carry translations.

Converting down to 5.5/5.5.1 is best-effort: there’s nowhere to put a per-note LANG or MIME, so they’re dropped, and TRAN translations have no home either — the converter keeps the primary note text and warns about what it couldn’t carry. This is a genuine loss going down, not a lossless round-trip; converting back up won’t restore the language, media type, or translations.

Validation notes. LANG, MIME, and TRAN under a note are 7.0 tags — any of them in a 5.5/5.5.1 file is flagged. In 7.0, a TRAN that has neither a LANG nor a MIME is flagged (it must declare at least one), and a MIME value outside the recognised media types is flagged. The app never blocks you from typing these — it warns; for sweeping a whole file (say, stamping a LANG onto many notes), reach for the transform panel rather than editing record by record.

See also: Write multi-line and long notes · Dates & places (the LANG/TRAN pattern on places) · Bulk transforms.

Next: attaching photos and documents — Multimedia →.