49 rules check a GEDCOM file for the defects that break imports in Gramps, webtrees, RootsMagic and elsewhere. The same explanations print in the terminal: gedlint --explain CODE.
Using gedlint
You can check a file right here in the browser (nothing is uploaded), or with the command-line tool:
gedlint tree.ged # report: what will break on import
gedlint --explain W401 # why one rule exists, how to satisfy it
gedlint --fix tree.ged # apply the provably safe repairs (.bak copy)
gedlint --fix --unsafe tree.ged # also format guesses, marked needs review
gedlint --format json tree.ged # machine-readable, complete
Each finding reads severity [code:category] line N: message; the code links to its entry below. Rule groups can be switched and re-leveled per project with a gedlint.toml file, and every pull request can be checked with the GitHub Action.
core 33 rules, on by default
E001 invalid-line-level
Start every line with a level number, one deeper at most
- error
- correctness
- fixable by --fix
- on by default
Why it matters and how to fix it
Why it matters
The level number at the start of a line is the only thing that says what the line belongs to. A line without one (a note or a source transcription that wrapped onto its own line is the usual cause) or a line that jumps two levels at once leaves the importer with nowhere to put the text: Gramps and webtrees list it in the import log and drop it, and lenient importers hang it off the previous person. Either way the note, place or source is missing from the tree you end up with.
How to fix it
Continuation text belongs on a CONT line one level deeper than the line it continues: "1 NOTE first part" followed by "2 CONT second part". gedlint --fix adds that prefix for you. For a level jump, add the missing intermediate line or lower the level so it grows by one at most.
Example
1 NOTE The boat left Barcelona at dawn
and the register spells the town Botarell
1 NOTE The boat left Barcelona at dawn
2 CONT and the register spells the town Botarell
E002 head-trlr-envelope
Open the file with HEAD and close it with TRLR
- error
- correctness
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A GEDCOM file is an envelope: HEAD first, TRLR last. Readers take the version and the character set from the header before anything else, so a file that starts with a record or ends without TRLR is commonly refused outright with "not a GEDCOM file", and a program that does open it treats whatever follows TRLR as if it were not there.
How to fix it
Move the HEAD record to the very first line and leave a single "0 TRLR" as the last one. Delete anything after TRLR, or move it above TRLR when it is a real record. Two exports concatenated into one file is the usual origin.
E003 duplicate-xref
Give every record its own identifier
- error
- correctness
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
The @I123@ identifier is how one record points at another. When two records share it, every pointer that names it becomes ambiguous and importers resolve it to whichever of the two they read last: children end up attached to the wrong parents, or one of the two people is swallowed by the other.
How to fix it
Renumber one of the two records to an unused identifier and update the pointers that meant that one. If the two records are the same person exported twice, merge them in your genealogy program and export again.
Example
0 @I1@ INDI
1 NAME Pere /Vilar/
0 @I1@ INDI
1 NAME Pere /Vilar i Soler/
0 @I1@ INDI
1 NAME Pere /Vilar/
0 @I2@ INDI
1 NAME Pere /Vilar i Soler/
E004 malformed-xref
Write identifiers as @XREF@, with no spaces
- error
- correctness
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
An identifier must be an @...@ token with no spaces and no nesting. A malformed one matches nothing, so every link into that record breaks at once: the person keeps their name but arrives in the new program without parents, children or sources.
How to fix it
Rewrite it as @ plus letters, digits or underscores plus @, for example @I42@, and make sure every pointer that references the record uses exactly the same spelling. Hand-editing a GEDCOM is where this normally comes from.
E005 orphan-continuation
Anchor every CONT and CONC to the line it continues
- error
- correctness
- fixable by --fix
- on by default
Why it matters and how to fix it
Why it matters
CONT and CONC continue the value of the line directly above them, one level up, and they never nest inside each other. One that hangs from nothing, or from another CONT or CONC, continues nothing: strict importers drop the text and lenient ones paste it into a neighbouring field. Long notes and record transcriptions are what usually come out mangled. A CONT nested under a CONC has only one possible meaning: it continues the same value the CONC continues, and only its level number is wrong.
How to fix it
Put the CONT or CONC line exactly one level below the value line it belongs to, and never chain one under another: "1 NOTE line one", "2 CONT line two", "2 CONT line three". gedlint --fix rewrites the level of a nested continuation for you, and only the number in column one changes, so you can judge the result against the text. A CONT or CONC with no line above it at all is left for you to place, because only you know which value it was meant to continue.
Example
1 NOTE A long note
2 CONC that wraps
3 CONT across lines
1 NOTE A long note
2 CONC that wraps
2 CONT across lines
E007 conc-in-gedcom7
Drop CONC from 7.0 files and carry long values on CONT
- error
- correctness
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
GEDCOM 7 removed CONC and reserved the tag (spec 1.3), so a 7.0 reader is entitled to refuse the file outright or to skip the line. Skipping it costs you the tail of the value: a long note or place name arrives cut off exactly where the exporter chose to split it, and nothing says so.
How to fix it
Join the CONC fragments back into the value of their parent line, which 7.0 allows because it has no line-length limit, and keep CONT only where you want a real line break. Staying on 5.5.1 is the other valid answer if you are not migrating yet.
E008 duplicate-singleton
Keep the one-per-record fields to a single instance
- error
- correctness
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
The specification allows exactly one SEX per person, one HUSB and one WIFE per family, one GEDC in the header, and one of each detail such as DATE, PLAC or CAUS inside a given event block. A second copy is almost always a merge leftover, and importers silently keep whichever they read first or last: the birth date your program shows afterwards may not be the one you meant to keep.
How to fix it
Decide which value is right, delete the other, and give genuinely different information its own block. A second marriage is a second MARR event, not a second DATE inside the first one.
E009 missing-required-substructure
Supply the substructures the specification requires
- error
- correctness
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
Some lines are not optional. The header needs GEDC with its VERS, which is how a reader learns whether the file is 5.5.1 or 7.0; in 7.0 a custom EVEN or FACT needs a TYPE, an LDS ordinance STAT needs a DATE, a REPO or SUBM record needs a NAME and an OBJE record needs a FILE. Without the version the importer guesses, and guessing wrong changes how dates, names and the character encoding are read for the entire file; without the record-level lines the repository, submitter or photograph arrives nameless or pointing at no file at all.
How to fix it
Add the missing lines: "1 GEDC" with "2 VERS 5.5.1" (or 7.0) inside HEAD, a "2 TYPE ..." under each custom EVEN or FACT, a DATE under each ordinance STAT, a "1 NAME" under each REPO and SUBM record and a "1 FILE" (with its FORM) under each OBJE record.
E010 record-requires-xref
Give INDI, FAM, SOUR, REPO, SUBM and OBJE records an @xref@ (5.5.1)
- error
- correctness
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A 5.5.1 record of these six types is written with an identifier in its first line, and only a NOTE record may drop it. A record opened as "0 INDI" with no @xref@ has no name, so no FAMC, CHIL, SOUR or OBJE line anywhere in the file can ever point at it: strict importers refuse the record and lenient ones read it as an anonymous blob that drops out of every index and chart. 7.0 relaxed this and allows anonymous records, so this rule stays silent on 7.0 files. Hand-merging two files is the usual origin.
How to fix it
Give the record an unused identifier, "0 @I12@ INDI", and keep it stable across exports. Nothing may point at the record yet, but the next link you add now has a name to use. Converting the file to 7.0 is the other way out.
Example
0 HEAD
1 GEDC
2 VERS 5.5.1
0 INDI
1 NAME Anna /Riu/
0 @I2@ INDI
1 NAME Joan /Riu/
0 HEAD
1 GEDC
2 VERS 5.5.1
0 @I1@ INDI
1 NAME Anna /Riu/
0 @I2@ INDI
1 NAME Joan /Riu/
E101 invalid-utf8
Keep every character whole and the file in valid UTF-8
- error
- correctness
- fixable by --fix
- on by default
Why it matters and how to fix it
Why it matters
MyHeritage cuts long values at a fixed byte count, and when the cut falls inside an accented character its two halves end up on different CONC lines. What is left is not valid UTF-8: where "José" belongs the importer shows a replacement box or a truncated "Jos", and some readers refuse the file outright. The same rule fires when the file is not UTF-8 at all while presenting itself as UTF-8.
How to fix it
gedlint --fix rejoins the split characters, which is a safe and invertible repair. If the whole file is in a legacy encoding instead, convert it to UTF-8, or declare the real encoding in "1 CHAR" so readers stop decoding it as UTF-8.
Example
1 NAME Jos�
2 CONC � /Casals/
1 NAME José /Casals/
E201 broken-reference
Point only at records that exist in the same file
- error
- correctness
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A pointer such as "1 FAMC @F12@" promises that @F12@ is in the file. When it is not, the link is simply lost on import: the child arrives without parents, the citation without its source, the person without their photograph. A partial export of a larger tree, or a record deleted by hand, is the classic cause.
How to fix it
Either add the missing record to the file or delete the pointer that names it. In 7.0, @VOID@ is the correct way to say "deliberately nothing here". When the file came from a filtered export, re-export the whole tree instead.
Example
0 @I3@ INDI
1 NAME Rosa /Campdera/
1 FAMC @F9@
0 @I3@ INDI
1 NAME Rosa /Campdera/
E202 ancestral-cycle
Break the loop where a person becomes their own ancestor
- error
- correctness
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A directed cycle through parent links (a child attached as their own grandparent after a bad merge or a mistyped identifier) has no valid reading: chart generators recurse forever or stop at an arbitrary depth, relationship calculators report contradictory paths, and exporters either loop or drop whole branches without warning.
How to fix it
Follow the chain named in the message and unlink the wrong parent or child connection in your genealogy program, then export again. When two records describe the same person, merge them instead of linking them as parent and child.
U501 removed-in-gedcom7
Replace the 5.5.1 constructs that GEDCOM 7.0 dropped
- info
- upgrade
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
These lines are valid 5.5.1 and are not errors today: they only have no home in GEDCOM 7. RELA became the enumerated ROLE, HEAD.CHAR disappeared because 7.0 is always UTF-8, PEDI values are uppercase, and a BET range has to be complete and in chronological order. A 7.0 reader given them ignores or reports the line, so the relationship description or the date range stops travelling with your tree. One of the checks is not about the migration at all: a BET range whose years run backwards is reported on a 5.5.1 file too, because no reader expects a range to end before it starts.
How to fix it
When you migrate, swap RELA for an enumerated ROLE with a PHRASE holding the free text, delete "1 CHAR", uppercase the PEDI value, and write ranges as "BET <earlier> AND <later>". The migration guide is at gedcom.io/migrate. Apart from putting a backwards range the right way round, nothing has to change while you stay on 5.5.1.
U502 undocumented-vendor-tag
Declare the vendor extension tags that a 7.0 file carries
- info
- upgrade
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
Tags beginning with an underscore are private extensions: _MARNM for a married name, _UPD for MyHeritage's last-changed stamp, _APID for an Ancestry source link. They survive into 7.0 as undocumented extensions, which means every other program is entitled to drop them, and a married name recorded only in _MARNM is exactly what disappears when the tree moves to another program.
How to fix it
Keep the tags, and when you move to 7.0 declare them in a "1 SCHMA" block in the header so readers know what they mean. Copy anything you cannot afford to lose into a standard structure first: a married name fits a second "1 NAME" with "2 TYPE MARRIED" under it.
W102 encoding-artifact
Keep the bytes plain: no BOM, one line ending, no controls
- warning
- style
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A byte-order mark in front of "0 HEAD" stops many 5.5.x readers from recognizing the first line at all, so the file is rejected as malformed (7.0 recommends the BOM, and it is not flagged there). CRLF and LF mixed in one file confuse older parsers and make every later diff unreadable. Stray control characters ride along inside names and notes and surface as boxes or as broken text.
How to fix it
Save 5.5.1 files as UTF-8 without BOM, pick one line ending for the whole file, and remove the control characters from the values that carry them. None of that is automatic. Independently of this warning, and whether or not it fired, gedlint --fix always rewrites classic Mac CR line endings to LF: that is whole-file preprocessing, not a repair of this rule.
W202 asymmetric-famc-chil
Keep FAMC and CHIL pointing back at each other
- warning
- suspicious
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A parent-child link is written twice: the child says "1 FAMC @F1@" and the family answers with "1 CHIL @I1@". With only one half present, what you see depends on which half your program reads first: the child shows up in the family's list but has no parents on their own page, or the reverse. The missing half is usually gone for good at the next export.
How to fix it
Add the line that is missing. Every "1 FAMC @Fx@" in a person needs a matching "1 CHIL" in family @Fx@, and every CHIL needs its FAMC. Re-linking the child to the family inside your genealogy program normally restores both halves at once.
W301 implausible-lifespan
Check deaths before births and lifespans over 105 years
- warning
- suspicious
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A death before a birth, or a life longer than 105 years, is nearly always a mistyped year, a date read from the wrong column of a parish register, or two different people merged into one. Nothing breaks on import, but the mistake spreads: every age, generation gap and timeline your program draws is computed from these two dates.
How to fix it
Open the person and compare both dates against the source. If the record really is exceptional and correct, leave it alone: this rule asks you to verify, it does not claim the data is wrong.
W302 possible-duplicate-individual
Review same-name people born within two years of each other
- warning
- suspicious
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
Two records with the same name and birth years two years apart or less are the classic result of importing the same branch twice, or of a merge that matched nothing. Left alone they split one person's sources, children and photographs across two half-empty pages, and neither page tells the whole story.
How to fix it
Compare the two records. If they are the same person, merge them in your genealogy program, which keeps both sets of sources, and export again. If they are a nephew named after their uncle, which happens constantly, nothing needs to change.
W303 implausible-parent-age
Check parents implausibly young or old at a child's birth
- warning
- suspicious
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A parent under 13, a mother over 50 or a father over 70 at a child's birth usually means the child is attached to the wrong generation, most often a grandparent linked as a parent. The tree then has one generation too few, and every descendant chart and relationship calculation drawn from it is wrong from that point down.
How to fix it
Check whether the child belongs to this family or to the next generation, and check the two birth years for a transposed digit. Late fathers and very young mothers are real, so verify the record rather than assume the link is wrong.
W304 child-born-before-marriage
Check children born before the marriage date of their family
- warning
- suspicious
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
This is often simply true and needs no change at all. It is flagged because the other common cause is a wrong marriage year, or a child of an earlier union attached to the later family, which puts that child in the wrong household in every report and chart your program prints.
How to fix it
Verify the marriage date and which family the child belongs to. When the birth really does precede the marriage, leave it as it stands, or record the earlier union as its own family so the child sits where they belong.
W305 invalid-sex-value
Use the SEX values the version allows: M, F, U, and X in 7.0
- warning
- suspicious
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
SEX carries one letter: M, F or U in 5.5.1, plus X in 7.0. Anything else, a whole word or a blank value included, is not understood, so importers store U instead. The person then shows up with a neutral icon and drops out of the "sons" and "daughters" listings your program builds from this field.
How to fix it
Write "1 SEX M", "1 SEX F" or "1 SEX U", and "1 SEX X" only in a 7.0 file. Anything you want to say in words about a person's gender belongs in a NOTE, not in this field.
Example
0 @I4@ INDI
1 NAME Anna /Riu/
1 SEX Q
0 @I4@ INDI
1 NAME Anna /Riu/
1 SEX F
W306 invalid-enum-value
Spell enumerated values the way the specification lists them
- warning
- suspicious
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
Fields such as PEDI, ROLE, QUAY, RESN, NAME.TYPE, FAMC.STAT, an ordinance STAT, HEAD.CHAR and the media or format of a FILE take their value from a fixed list. A value outside the list is dropped rather than adapted: an adoption recorded as "2 PEDI adopted child" imports as an ordinary birth relationship, and the fact that the child was adopted is gone from the tree. In a 7.0 file a value matching the extension production, an underscore followed by uppercase letters, digits or underscores, is a legal extension and is never flagged.
How to fix it
Use the listed value named in the message; 7.0 wants the exact uppercase spelling, 5.5.1 accepts any case. When none of them fits, that is what OTHER is for: put it there and write the real wording in a PHRASE beside it, or, in 7.0, declare your own underscore-prefixed value in SCHMA.
W307 conflicting-duplicate-event
Reconcile single events recorded twice with different dates
- warning
- suspicious
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A person is born, christened, baptized, confirmed and buried once each, and a given marriage or divorce happens on a single date, so one of those events twice with two different dates is the fingerprint of a merge where neither date won. Programs keep one of them, usually the first, so the date you end up looking at may not be the researched one and the other is lost at the next export. A remarriage, MARR then DIV then MARR, is a legitimate sequence and is not flagged.
How to fix it
Keep the date you can source, delete the other, and put the rejected one in a NOTE if it is worth remembering. When both dates are right because they describe two different occasions, give each its own event block with its own PLAC and SOUR.
W308 child-born-after-parent-death
Check children born after a parent died
- warning
- suspicious
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A birth after the mother's death, or more than a year after the father's death, usually means the child is attached to the wrong parents or a death year lost a digit. Nothing breaks on import, but every descendant timeline and relationship path drawn below that link inherits the wrong household.
How to fix it
Compare the child's birth date against both parents' death dates in the sources. Fathers allow one year of slack for a posthumous birth; anything beyond that, or any birth after the mother's death, belongs to another family or needs a corrected year.
W309 child-born-before-parent-birth
Flag children older than their own parents
- error
- suspicious
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A child born in the same year as a parent or earlier cannot be that couple's child: the link almost always joins two generations, typically a grandparent recorded as a parent. Charts built from it lose a generation and every relationship below that point is computed one step wrong.
How to fix it
Move the child to the family where they belong, usually one generation down, or correct the birth year that carries the transposed digit. W303 already warns on wide gaps; this error marks the gap that cannot happen.
W310 chronological-event-sequence
Keep baptism, burial and death in chronological order
- error
- suspicious
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A christening or baptism before the birth, a burial before the death, or a baptism after the death is nearly always a date attached to the wrong event or the wrong person after a merge. Timelines and age calculations built from these dates place the person's whole life in the wrong order.
How to fix it
Open the person and compare each event date against its source, moving the stray date to the event it belongs to. Approximate, ranged, BEF and AFT qualified dates are not flagged, because an inexact date near a boundary proves nothing.
W311 marriage-before-birth-or-after-death
Keep marriages inside both spouses' lifetimes
- error
- suspicious
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A marriage dated before either spouse was born or after either spouse died usually attaches the wrong couple to the family or carries a marriage year from a different union. Family reports then show a household that could never have existed, with children assigned to it.
How to fix it
Verify the marriage date and that the two spouses are the right pair. When the date belongs to an earlier or later union, record that union as its own family instead of reusing this one. Each marriage in the family is checked, and BEF or AFT qualified dates are not flagged against the side their uncertainty covers.
W312 spouse-role-sex-discordance
Match HUSB and WIFE roles to the recorded sex
- warning
- suspicious
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A family whose HUSB is recorded female while its WIFE is recorded male is usually a swapped pair from manual editing or a bad import. Programs that list sons and daughters or draw pedigree symbols from these two fields then place the parents on the wrong sides of every chart. A single mismatched side alone is never flagged, because a same-sex marriage is legitimately recorded with two men or two women in these slots.
How to fix it
Swap the two spouse links back, or correct the SEX value that is wrong. Records without a usable SEX value are never flagged, so only a jointly inverted pair needs review.
W401 url-in-place
Keep URLs out of PLAC and put the link where links belong
- warning
- style
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
MyHeritage writes the address of its place catalogue into the place name itself. The place then imports as the literal text "Sabadell, https://...", which matches nothing that anyone else wrote for the same town: your place index fills up with near-duplicates, and no map lookup or place merge resolves them.
How to fix it
Trim the value back to the place name and move the link into a NOTE, or into a "2 WWW" line in 7.0. The name should read the way a person would write it: "Sabadell, Vallès Occidental, Barcelona, Spain".
Example
2 PLAC Sabadell, https://www.myheritage.es/lugares/sabadell
2 PLAC Sabadell, Vallès Occidental, Barcelona, Spain
3 NOTE https://www.myheritage.es/lugares/sabadell
W402 nonstandard-name-or-date
Write NAME and DATE values in the shape the format defines
- warning
- style
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A surname is delimited by a pair of slashes and a date is "DD MMM YYYY" with an English three-letter month. With the slashes unbalanced the importer reads the whole string as a given name, so the person files under the wrong letter and has no surname in any index. A date written "gener 1901" or "about 1901" is stored as unparsed text: it does not sort, does not filter, and never lands on a timeline.
How to fix it
Balance the slashes around the surname, as in "1 NAME Joan /Puig i Ferrer/", and write dates as "12 JAN 1901", using ABT, CAL or EST for approximations and "BET x AND y" for ranges. Keep the original wording in a PHRASE or a NOTE when it matters.
Example
1 NAME Rosa /Prat
1 BIRT
2 DATE 12 gener 1901
1 NAME Rosa /Prat/
1 BIRT
2 DATE 12 MAR 1901
W403 html-in-note
Store notes as plain text, not as HTML
- warning
- style
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
Exporters that keep notes in a rich-text editor write the markup out exactly as it stands, so <br>, and whole <notexml> wrappers end up inside the note. GEDCOM notes are plain text: the receiving program prints the tags literally, and a note that looked like three tidy paragraphs on screen arrives as one paragraph full of angle brackets.
How to fix it
Convert the markup to plain text before exporting: a <br> becomes a real line break on a CONT line and a becomes an ordinary space. Delete the wrapper elements entirely.
W404 nonstandard-age-value
Write ages as durations: 42y 6m, not 42 or 3 months
- warning
- style
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
AGE carries a duration with a letter per unit: "76y", "42y 6m", "11m 3w 6d", optionally bounded by < or >. A bare number ("76") or spelled-out units ("3 months") is not an age to any reader: the value is stored as unparsed text, age-at-event fields show it raw or empty, and sorting and averaging over ages silently skips every one written this way. 5.5.1 also allows the words INFANT, CHILD and STILLBORN, which 7.0 dropped.
How to fix it
Give every unit its letter: "2 AGE 76y", "3 AGE 3m". Ages under a FAM event's HUSB or WIFE take the same form. Put anything a duration cannot say, such as "about three months", in a NOTE beside the age.
Example
1 DEAT
2 AGE 76
1 DEAT
2 AGE 76y
W405 missing-calendar-escape
Mark Hebrew and French Republican dates with their calendar escape
- warning
- style
- no automatic fix
- on by default
Why it matters and how to fix it
Why it matters
A 5.5.1 date in the Hebrew or French Republican calendar must start with the calendar escape, @#DHEBREW@ or @#DFRENCH R@. Without it the month code (TVT, NIVO, SVN...) is just a strange word: importers read the whole value as unparsed text or drop the date, so a burial dated in the Hebrew calendar arrives with no date at all. Older Jewish and French-Canadian exports are where the bare form usually comes from.
How to fix it
Prefix the value with the escape the month names imply: "2 DATE @#DHEBREW@ 2 TVT 5758" or "2 DATE @#DFRENCH R@ 11 NIVO 0006". 7.0 names the calendar inline ("HEBREW 2 TVT 5758") and needs no escape.
Example
2 DATE 11 NIVO 0006
2 DATE @#DFRENCH R@ 11 NIVO 0006
hygiene 13 rules, off by default
W701 polluted-name
Remove notes, occupations or nicknames from name fields
- info
- style
- no automatic fix
- off by default
Why it matters and how to fix it
Why it matters
Consumer software indexing names cannot separate notes or occupations from actual names. A parenthetical, asterisk or digit breaks the name index. The rule reads "1 NAME" and the "2 SURN" subtag, and reports a record once.
How to fix it
Move the notes, occupations or nicknames to their proper tags like NOTE, OCCU or NICK.
W702 all-caps-name
Avoid all-caps surnames
- info
- style
- needs review (--fix --unsafe)
- off by default
Why it matters and how to fix it
Why it matters
Fully capitalized surnames are a long-standing genealogical convention rather than a defect, and title casing is lossy for MCDONALD, O'BRIEN, DE LA O and most Iberian particles. The rule reads the surname slot of "1 NAME" and the "2 SURN" subtag, and reports a record once; a given name is out of scope, so the repair never title-cases one.
How to fix it
Write names in standard capitalization. You can apply a potentially unsafe automatic repair using --fix --unsafe.
W703 malformed-place
Remove doubled commas from place names
- info
- style
- fixable by --fix
- off by default
Why it matters and how to fix it
Why it matters
Doubled commas inside PLAC break the place index in consumer software, causing near-duplicates and breaking map lookups completely.
How to fix it
Remove the extra commas from the place name. The automatic repair gedlint --fix does this for you automatically.
W704 impossible-sibling-spacing
Review siblings born less than eight months apart
- warning
- suspicious
- no automatic fix
- off by default
Why it matters and how to fix it
Why it matters
Two children of the same mother born one to eight months apart, on exact dates, are in practice either one person entered twice with slightly different dates or children of two different unions merged into a single family. Left alone, the duplicate splits sources across two pages and the merged household misleads every sibling chart.
How to fix it
Compare the two birth dates against the parish register. Merge the pair when they are one person, or split the later union into its own family when two mothers were merged. Twins sharing the same day are never flagged, and families with no recorded mother are skipped because spacing cannot be measured without her.
W705 alive-but-too-old
Mark very old people without a death date as deceased
- warning
- suspicious
- no automatic fix
- off by default
Why it matters and how to fix it
Why it matters
A person born more than a century before the newest date in the file and still without a death date is almost always dead with the death missing from the record. While they stay listed as living, every search for the very old and every count of the living in your program includes people who cannot be alive, and record hints keep arriving for them.
How to fix it
Find the death date in the parish register or the civil records and add it, or record the person as deceased when the exact date is unknown. When the person really is alive and exceptional, leave the record as it stands: this check asks for verification, not for invention. The age limit is the max-alive-years threshold.
W706 large-spouse-age-difference
Check spouses whose births are decades apart
- warning
- suspicious
- no automatic fix
- off by default
Why it matters and how to fix it
Why it matters
Spouses born a generation or more apart are usually a mistyped year or a second union recorded on the first family: one birth year of 1991 instead of 1919 moves a whole household by seventy years. Programs draw the couple side by side, so the mistake hides in plain sight until a descendant chart makes the gap visible.
How to fix it
Compare both birth years against their sources and check whether the marriage belongs to an earlier or later union of one of the spouses. Adjust the max-spouse-gap threshold in [lints.thresholds] when your tree legitimately holds wide gaps, so only the certain errors keep reporting.
W707 married-too-young
Check marriages before either spouse grew up
- warning
- suspicious
- no automatic fix
- off by default
Why it matters and how to fix it
Why it matters
A marriage dated when a spouse was still a child usually carries the wrong marriage year or attaches the wrong couple to the family: parish registers sometimes date the banns where the marriage belongs. The household your program prints from that date joins two people who could not yet have married, and any children attached to it inherit the wrong start.
How to fix it
Verify the marriage date and that the two spouses are the right pair, moving an early union to its own family when it belongs there. A spouse who died in childhood is flagged the same way. The minimum age is the min-marriage-age threshold, so raise it or lower it to match what your sources consider marriageable.
W708 siblings-same-first-name
Review siblings who share a first name
- info
- suspicious
- no automatic fix
- off by default
Why it matters and how to fix it
Why it matters
Two children of one family with the same first name are often the same person entered twice with slightly different dates, splitting sources and photographs across two half-empty pages. A namesake after an infant death is the legitimate counterpart, which happens constantly and is why this finding stays a notice rather than a warning.
How to fix it
Compare the two records, including death dates: merge them in your genealogy program when they are one person, and leave them alone when the elder namesake died young. Nothing needs to change for cultural naming patterns that reuse names deliberately.
W709 disconnected-individual
Reconnect or remove people linked to no family
- info
- suspicious
- no automatic fix
- off by default
Why it matters and how to fix it
Why it matters
A person with no parents, spouses or children floats outside every pedigree, descendant chart and relationship calculation your program draws: they are invisible in all of them. Detached leftovers usually arrive when a branch is deleted or moved and one record stays behind, exactly what this check collects.
How to fix it
Attach the person to their family, or delete the leftover record when it duplicates someone already in the tree. Forests of genuinely separate trees in one file can silence this check in [lints.rules] without losing anything else.
W710 name-spacing-affixes-short-years
Clean spacing, affixes, short years and missing sex in names
- info
- style
- no automatic fix
- off by default
Why it matters and how to fix it
Why it matters
Double spaces, leading blanks, a Dr. inside the given name or a Jr. inside the surname break name indexes: searches miss the person unless the user guesses the exact quirk. A two-digit birth year sorts nowhere and a missing sex drops the person from every sons and daughters listing, so these small defects share one check.
How to fix it
Remove the extra spaces, move prefixes and suffixes to their own fields, write all four year digits, and record M, F or U for every person. Each half of this check is independent: fix what is wrong in your sources and leave the rest, since house names and particles are legitimate text.
W711 children-different-surnames
Review families whose children carry different surnames
- info
- suspicious
- no automatic fix
- off by default
Why it matters and how to fix it
Why it matters
Children of one household with different surnames often mean a child of an earlier union recorded on the later family, or a second family merged into the first: every sibling chart printed from that household then mixes two lines. Remarriage, adoption and double surnames make this common enough to stay a notice, but the split is worth one look.
How to fix it
Check which union each child belongs to and move misplaced children to their own family, or correct the surname that carries the typo. When the mix is real, for example after a remarriage, leave it and silence the single finding in the baseline.
W712 place-resembles-cause-or-date
Move causes of death and dates out of place names
- info
- style
- no automatic fix
- off by default
Why it matters and how to fix it
Why it matters
A death place holding Holocaust or died of pneumonia belongs in the cause field, not on the map: geocoders fail on it and place indexes fill with entries no other tree shares. A place holding a year or a month is the mirror mistake, a date typed into the wrong field that then never lands on any timeline.
How to fix it
Move the cause into CAUS and the date into DATE, leaving the place as a person would write it. Only a human knows which field the text belongs in, so this check never repairs itself: correct the line by hand.
W713 line-too-long
Split lines exceeding the 255-character GEDCOM limit
- info
- style
- no automatic fix
- off by default
Why it matters and how to fix it
Why it matters
GEDCOM 5.5.1 limits physical lines to a maximum of 255 characters, including delimiters and terminator. Many parsers use fixed buffers or reject longer lines, which can truncate notes, citations, or text payloads. Multibyte encodings such as UTF-8 can also exceed 255 bytes even when character count is within limit.
How to fix it
Split the long line using CONC continuation lines (at level + 1 for standard tags like NOTE, or at the same level for existing CONT/CONC lines).
Example
1 NOTE [T1] Llibre de família: Fill primer... pàgina 20. Confirmació el 9-10 de febrer de 1967 a Crist Rei pel bisbe Benjamí de Arriba y Castro. 1a Comunió el 15 de maig de 1966 a Crist Rei. Aquest registre conté una descripció molt extensa dels esdeveniments familiars que supera el límit permès per la norma GEDCOM 5.5.1 en una sola línia de text.
1 NOTE [T1] Llibre de família: Fill primer... pàgina 20. Confirmació el 9-10 de febrer de 1967 a Crist Rei pel bisbe Benjamí de Arriba y
2 CONC Castro. 1a Comunió el 15 de maig de 1966 a Crist Rei. Aquest registre conté una descripció molt extensa dels esdeveniments familiars que supera el límit permès per la norma GEDCOM 5.5.1 en una sola línia de text.