🌐 Also available in: Deutsch · Español · Français · Nederlands · 简体中文

Overview

Gramps Connect is an HTML-based way to work on a family tree built with Gramps, the free genealogy software. It follows the same layout and vocabulary as Gramps itself, so if you've used Gramps before, it should feel familiar rather than like a different program you have to relearn. Two things set it apart: it stays fast even on very large trees, and it's built for more than one person to be working on the same tree at the same time.

It comes in two forms. A standalone version runs entirely on your own computer — a genuine alternative to Gramps Desktop for day-to-day work on your own tree, not a limited preview of anything else, and nothing you do in it is sent anywhere (see Installing). A shared, hosted version lets a whole family log in and work on one tree together, which is where the live collaboration features described below come into their own (see Deploying). Either way, the interface is the same — the only difference is whether anyone else is in the tree with you.

Working together

• Know which tree you're in. The header names the active tree next to the Gramps Connect logo, so if you're signed into more than one (or sharing a hosted instance with other family trees), it's always clear which one you're looking at.
• Know when the app itself has been updated. On a shared, hosted instance, a tab you've had open for a while can end up running an older build than what the server is now serving. Gramps Connect notices and shows a dismissible "Update available" notification with a Reload button — it never reloads the page for you, since you might have unsaved draft edits open.
• See each other's changes as they happen. When someone else corrects a date or adds a person, your screen updates on its own — no reloading, and no risk of working from a copy of the tree that's already gone stale. Anyone who's changed something in the last few minutes shows up as an avatar next to the user menu, so you can see who else is actively working in the tree with you right now. See Architecture for how this actually works under the hood.
• See who changed what, when. Every record has a History button — open it for a log of that record's own edits (who, when, added/updated/ deleted), newest first, and click any entry for a field-by-field before/after diff. The after-the-fact complement to live sync above: that shows you changes as they happen, this lets you look back later. See Data Model and Editing for more.
• Discussions: threads that can be about something. Discuss a specific record with one click and keep chatting in a floating window while you browse — it never takes over the page you were on — or open the Discussions view and start one from scratch, linking in whatever People, Sources, Citations and Repositories a research question actually turns on, so a discussion can grow into a real gathering point for one line of research, not just a comment thread. One-on-one messages work the same way, just unlinked to anything. See Messaging for details.
• Shared results. When someone runs a report or exports the tree, the finished file shows up where everyone can find and download it, not just in that person's own folder. Clicking Download on one of these confirms with an in-app toast once the save hands off to the browser/OS — helpful on desktop, where the native save dialog it triggers can otherwise be easy to miss. Afterward it asks whether to keep the generated file as a media object in the tree (green Save) or not (plain Don't Save) — Save, or just dismissing the dialog, is the safe default; either way it's a quick regenerate away, so the choice isn't a big deal. Most generated files (and any other Media item) can be viewed in the browser via a View button, not just downloaded — see Data Model and Editing for which formats. An export that had to leave something out — the GEDCOM 7 export reports, for example, data GEDCOM 7 has no place for — says so in a yellow "Export ready" notice, and the full list is attached to the exported file as a note, so anyone who opens it in the Output view sees what's missing. Choosing Don't Save removes that note along with the file. (This needs a gramps-web-api server from v3.23.0 on.)
• Tree owner administration. A tree's owner gets an Administration dialog from the user menu, with a "My Tree" tab covering the tree's name and its usage against any configured people/media quotas, and a "Users" tab alongside it for managing accounts on that tree. Server-wide settings (e-mail/SMTP, BASE_URL, FRONTEND_URL) aren't edited in the app: set them in the server's environment variables or config file (see Installing and Deploying). gramps-web-api is phasing out settings stored in its database; if any are still there, Help → System Information lists them with a warning.
• Tree preferences. Administration → Preferences sets how this tree's dates, names and places are written, for everyone using it in Gramps Connect: a date format, a name format (the standard Gramps ones plus any custom formats saved in the tree), and Gramps' place formats: automatic place titles on or off, which format to use, and a list of formats you can add to, each choosing which levels of the place hierarchy to show, a language, how a house number joins its street, and whether to reverse the order, with an example of each on a place from your tree. Only the tree's owner (or a site admin) can change them. They apply across the app: dates in tables, details, the Timeline, stories, search results and the Tree, Fan and Family charts; place titles in the Places and Events tables, details, Map, Timeline, stories and search results, with an event's place named as it was on the event's date (Gramps' dated place names and enclosing places); and names in details. Date fields in edit dialogs show and accept the same date format. Dates are written in your interface language, the way Gramps desktop writes them in that language: its month names, its words for "about", "between … and" and the like, and its own layouts (German "12. März 1854", French "12 mars 1854", British English 12/3/1854). Date fields accept dates typed in that language too. The date format list is your language's own Gramps list, with an example of each, as in Gramps desktop's Preferences. Most formats exist in every language ("Day Month Year" and the like), and choosing one sets it for everyone, each in their own language. A format only your language has (German "Numerisch mit führenden Nullen", French "JJ/MM/AAAA") applies to people using that language; everyone else keeps the shared one, which the setting shows underneath. This covers every language Gramps writes dates in (43), including those whose month names change form with the words around them: Russian writes "март 1789" but "до 4 марта 1789", and Czech, Finnish, Croatian, Slovak, Slovenian and Ukrainian work the same way. Where Gramps desktop itself writes a date it can't read back, or fails on one, Gramps Connect writes it correctly instead. Only your own language is downloaded, when you first need it. Dates in the Chinese, Korean and Vietnamese lunar calendars (new in Gramps 6.2) are shown and read too, in Chinese, Korean and Vietnamese the traditional way ("2024年正月1日", "2024년 정월 1일", "Năm 2024 Tháng Giêng Ngày 1", with 闰/윤 for a leap month). When the server runs Gramps 6.2 or later, a date's full editor offers those calendars, with a "Leap month" switch beside the month; an older server can't format or sort them, so there they're only offered for a date that already uses one. New reports start out with the same date and name formats. Exports, and the report's place format, keep the server's own Gramps settings. The Places table sorts by each place's own name, then by its stored title, so it lines up with automatic titles that start with the place's name, as the standard "Full" format does. The first time places are shown with automatic titles, Gramps Connect downloads the places list once more to pick up the extra information it needs. Under New records, set the Gramps ID format for each kind of record, like Gramps' own I%04d (I0001, I0002, ...); "Use Gramps' default IDs" fills in all nine. Gramps Connect gives a new record the next number after the highest one already in use (unlike Gramps desktop, it doesn't go back to fill gaps). If someone else takes the same ID at the same moment, it simply tries again. A type left empty gets standard Gramps IDs (I0001, F0001, ...) from the server, as before. These formats apply to records created in Gramps Connect, not to imported files: those keep the IDs in the file (a GEDCOM's @I12@ becomes I0012), and only an ID that's already taken is renumbered. Import from Gramps desktop… copies the same settings, ID formats included, from Gramps on your computer: choose its gramps.ini (Linux and macOS: ~/.config/gramps/gramps60/; Windows: %APPDATA%\gramps\gramps60\), plus place_formats.xml from the folder above it if you've made your own place formats. A preview lists each setting found, what it would become and what it is now; settings you never changed on desktop are marked "Gramps default" and left unticked. Because Gramps numbers its date formats differently in each language, pick the language your desktop Gramps runs in. Nothing is saved until you press Save.
• API keys. User menu → API keys… lists the keys that let Gramps on your computer, or another program, open your family tree, with when each was created and last used. Create one with a name like "Gramps on my laptop", copy it once, and paste it where the program asks for a Gramps Web API key (GRAMPS_WEB_API_KEY). Removing a key cuts off just that program or computer, e.g. a lost laptop. A key can read and edit the tree but not change your account. Keys that Gramps Web Sync creates for itself show up here too. On a server older than gramps-web-api 3.23.0 the dialog instead offers to copy your current session's key, which has full access, never expires and can't be removed later, not even by changing your password.
• Researcher information. Help → Researcher shows the tree's researcher contact info (name, address, phone, email) — the details GEDCOM export headers conventionally carry. Anyone on the tree can view it; an Edit button to change it only shows for the tree's owner.
• System information for bug reports. Help → System Information shows the versions of everything involved (Gramps, Gramps Web API, Gramps Connect, Gramps Object Query Language) and the server features that affect what you see, such as whether email is set up and which files get thumbnails, with a Copy button for pasting into a report. A site admin, or the owner of a single-tree server, also sees a Warnings section listing any server settings that are deprecated and what to use instead.
• This wiki, without leaving the app. Help → Documentation opens this wiki's pages inside the app itself — sidebar navigation, in-app links between pages, images — rather than switching to a browser tab. An "Open on GitHub" link in the dialog still reaches the real wiki page for anyone who wants to edit or comment. The app's own "Read the overview" link (Help → About) still opens this wiki directly in a new tab.
• Translated pages, when they exist. If a page has a translation for the app's current language — stored as an ordinary sibling wiki page, e.g. Home.de.md — Documentation shows that instead, falling back to English silently for any page not yet translated. The sidebar navigation is translated the same way. This whole wiki has complete German, French, Spanish, Dutch, and Simplified Chinese translations as of now; more languages are planned.

Telling the story

• Automatically generated life stories. For any person or family, the app puts together a narrative slideshow of their lives — their events, the places they happened, and any related photos — with a short written description for each moment. These are editable, not fixed. Generating one offers a couple of options first: for a person, whether to pull in their families too (spouse, children, parents, siblings — not just their own events); for a family, which members' own births and deaths to include.
• A family blog. Write your own posts — a title, author, free-text body and photos — rather than a generated one. The Blog view in the sidebar lists every post as a browsable magazine-style feed; click View to see one full-screen, and the newest post also shows up on Home. Under the hood a post is just an ordinary Source tagged "Blog" with its body as an attached Note, so it's still fully searchable and editable like any other record.
• Photo comparisons. Place two photos on top of each other — useful for "then and now" pairs, or comparing photos of the same person at different ages.
• Tagging photos, and clicking through them. Draw a region on a photo to mark who or what's in that part of it. Open the photo full-screen and click directly on a tagged face or object to jump straight to that person's or record's page.

Exploring your tree

• Drill down without losing your place. Pick a person (or family, place, event...) from a list, and everything related to them — their events, family, photos, notes, sources — appears alongside it. Click into any of those and its own details open below, while the list and your original selection stay exactly where they were, however deep you go.
• Search across your whole tree at once. One search box looks through every kind of record — people, families, events, places, sources — together, laid out like a search-engine results page, ranked by how well each result matches, with a snippet of context. Each list also has its own search box, which by default does a fast plain-text match against that record type's common fields; a checkbox next to it switches the same box into GOQL, a small query language for much more specific questions — everyone with a given surname born in a certain place before a certain year, say, or every family where the mother died before the father. Typing a new search, clearing it, applying a saved/custom filter, or clicking a column header to sort all keep whatever record you had selected exactly where it was, as long as it's still in the results; if it isn't, selection falls back to the first row of what's now showing, the same "don't lose your place" treatment drilling down already gets.
• Curated filters, no query language required. A "Filters" button next to every primary list's title (People, Families, Events, Places, Repositories, Sources, Citations, Media, Notes — every list except Tags) opens a dialog for picking one from your saved combinations, or building your own. "Load a saved filter…" reloads a whole named combination you saved before (its empty first entry starts fresh); the rest of the dialog stays tucked behind a collapsed "▸ Edit options" toggle so picking a saved filter and hitting Apply stays a two-click job, with the full editor one click away for anyone who needs it. Opening "Edit options" reveals a left-aligned "Custom Rules" button (styled like the page's own "Filters" button, not a plain text link) and, under a small "Filter Builder" heading, one AND/OR/NOT rule-group editor — Females/Males, no recorded birth date, missing parents, has media, tagged with a name you type in (any tag on the tree, not a fixed list), born or died between two dates you type in (any date Gramps understands, not just a bare year), and dozens more of the same everyday rules the desktop app's old Custom Filter rules offered, as plain checkboxes grouped by category, the same ones "+ Add rule" always opens to (already expanded when the list is empty, so applying a single rule needs no extra click). Combine several with AND/OR, nest a rule group inside another to mix the two, and negate any single rule or whole rule group with its own checkbox — no separate "not" filter to create, unlike the desktop app. Under the hood it builds the same GOQL the search box's checkbox mode uses, shown read-only underneath, also inside "Edit options". (The curated checkbox list itself currently only covers People and Family, matching the desktop app's own rule set for those two; every other list still gets the full dialog — building your own rules, saving/loading whole filters — just with an empty built-in list to start from.) Loading a saved filter and then editing its rules directly (inside "Edit options") is all it takes to change it -- a small "Unsaved changes" note appears next to the dropdown as a reminder while you do, and switching to a different saved filter (or back to empty) while it's showing asks you to confirm first, so an edit in progress is never silently thrown away by picking something else from the same dropdown; "Save" (enabled once you've actually changed something) saves those changes back to that same filter, "Copy…" keeps the original untouched and makes a separate one instead — defaulting to "that filter's name (copy)" so it's not left blank — and "Save…" (nothing loaded yet) gives a fresh arrangement a name for the first time; either one rejects a name that's already used by another saved filter in that same list, right in the naming dialog, rather than letting a second filter silently shadow the first. "Delete" removes the currently loaded saved filter and empties the Filter Builder along with it — it lives in the button row at the bottom alongside Clear/Save/Apply, disabled whenever nothing's loaded ("New Filter"). Need a rule that's not in the built-in list? "Custom Rules", inside "Edit options", opens its own small manager — name and save a raw GOQL snippet (the one place raw query text is accepted anywhere in this feature), with the same circled-"i" syntax reference next to it that the search box's own GOQL mode uses, for whichever list you opened it from; it's actually run against your tree in the background as you type, so "Create"/"Save" only enable once it's confirmed valid, catching a typo right there instead of the next time the rule gets used. A custom rule can take its own named, typed parameters, just like a built-in rule (e.g. the built-in tag/date rules already do) — add one or more {name} params (String or Integer), reference each as {name} in the GOQL, and once saved it shows a fill-in-the-value field right in "+ Add rule", same as any built-in parameterized rule. Edit or delete any you've made, and each one shows up as an ordinary, reusable rule in "+ Add rule" from then on. There's no separate "Cancel" button on the main dialog — it writes nothing until you actually click Apply, Save, or Copy, so closing it any other way (the × or clicking outside) already does the same thing. Whenever a filter is active, the list header itself shows a plain-language summary next to the "Filters" button and its clear ("×") button — e.g. "Females AND NOT (Widowed OR Divorced)" — so you can tell what's applied without opening the dialog.
• Family tree charts. Ancestor and descendant charts, including a circular "fan" style with an option to shade each person's slice by how long they actually lived, so long and short lives are visible at a glance. Its status bar has "+"/"−" buttons to grow or shrink how many generations are shown — shrinking never re-fetches anything, so growing back out is instant — plus an export icon (also on the ordinary ancestor/descendant chart) that saves the chart as PNG, JPEG, SVG, or PDF, the same idea as the original Gramps desktop's own chart export. It exports the whole chart by default, however far you've zoomed or panned on screen (or just the current view, if you prefer), in light print-friendly colors even in dark mode. Images can be saved at a pixel size you choose; SVG and PDF stay sharp at any size, and PDF lets you pick the paper size (A0–A5, B3–B5, Letter, Legal, Tabloid, ANSI C/D), orientation, and margin. A rotated fan can be exported as shown or upright. Names in Latin, Greek, or Cyrillic scripts stay real, selectable text in the PDF; a chart with names in other scripts (Chinese, Arabic, Hebrew, …) is saved as a high-resolution picture inside the PDF instead. The dialog remembers your last choices. Each wedge shows the person's name with their birth and death dates underneath, as much as fits, each line curved along its ring. A name too long for one line splits onto two (given names, then surname); where only one line fits, the given name is kept, since that's what tells generations apart. In the narrow wedges of distant generations the text turns to run outward from the center, fitting far more of each name. With "Flip labels" on (the default), text that would otherwise read upside down — in the lower half of the fan, or wherever you've rotated it to — is turned to read the right way up (and an upright export of a rotated fan flips them for the upright view). Ctrl+drag (or Cmd+drag) anywhere on the fan — in either shading mode — spins it freely around its own center, to bring a particular branch to the top. Hold Shift as well to turn it in 15° steps, and a drag released within a few degrees of upright lands exactly upright. While the fan is turned, a small compass button in its top-right corner shows which way it's pointing; click it to spin the fan smoothly back to its original orientation. A third "Generations" style shows a person's parents and their full sibling row — including half, step, and adopted siblings, which the ordinary ancestor chart has no room to show at all — with a "+" to keep expanding outward: a full sibling row appears at every generation you expand to, not just the person you started from. Besides the scrollbars, you can click-and-drag anywhere on the diagram to pan it around, the same way the ancestor/descendant and fan charts already work. A muted gray "−" appears alongside any "+" once that branch has actually been revealed, to fold it back down again without losing anything — the underlying data stays loaded, so expanding it again is instant. Full siblings are grouped together visually with one shared "+" (they always expand into the same parents), while a half- or step-sibling branch gets its own group and label instead, each with its own line drawn up to its own father/mother boxes rather than one ambiguous line in the middle. A group is labeled "half" only when it shares one parent by birth; a group that shares no parent by birth — e.g. a later spouse's own children from an earlier marriage — is labeled "step" instead, even though that later marriage's family record is otherwise indistinguishable from a half-sibling one. Selecting a person and choosing "Expand spouses" from their detail card shows their spouse(s) beside their own card, wherever it appears in the graph — each spouse shown as their own full sibling group (with their own "+" to keep expanding), not just a bare name, since every person here belongs in a sibling group. Their children's own line down to them updates to connect to both parents once the spouse is expanded, rather than just the one person originally shown. A person with children from more than one marriage gets a separate children box per marriage instead of one box merging every child together, each with its own connector line drawn up to that specific marriage's two parents. Any card whose tie to its parent isn't a plain birth relationship — a sibling or a child alike — carries its own small badge naming it (Adopted, Stepchild, Foster, Sponsored, Unknown), the same Gramps relationship vocabulary used everywhere else in the app. A horizontal divider marks the boundary between each generation. A "Compact" checkbox (next to the chart's own instructions) drops each card's photo, puts birth/death dates beside the name instead of below it, and lists a sibling or children group as a vertical stack instead of side by side — useful once a sibling row gets wide.
• Maps. See where events took place, and switch the map's appearance to look the way the area did during that historical period rather than a modern map. Every map overlay — outline a family farm's boundary, mark a route someone traveled, or overlay an old survey map or photo onto its real location — belongs to at least one place, and is added from that place's own "Map overlays" section: one button offers both drawing a brand new item and attaching an already-existing overlay here too. An overlay can span several places at once (a boundary or route that covers more than one, say) — it just can't be attached to the same place twice. The drawing editor itself lets you place lines, shapes, and images, dragging an image's four corners independently (free-transform warping) to line it up with the real terrain, and set each image overlay's own opacity and stacking order (which one sits on top when several overlap, like an old county map layered under a more detailed township survey) — a description is required before it can be saved, same as the place attachment. Once saved, a live panel on the map itself lists every overlay and drawn region on the currently open place and on whatever it encloses — opening a state shows its own overlay alongside each of its counties', not just its own. If the next level down has none of its own (say a country whose regions carry no outline but whose smaller divisions do), it keeps descending until it finds a reasonable number of overlays or runs out of places, rather than stopping after exactly one level down — where you can hide any of them or preview a different opacity for the rest of this session — a quick way to compare a modern map against an old one without touching the saved settings — and clicking one flies the map to fit its full extent. A child place's shape or image renders on top of its parent's rather than underneath, so a smaller overlay never disappears under a larger one that encloses it. An overlay's visible date range comes from the date on whichever place you're currently viewing it from — so a farm outline with no date shows all the time, while an old map only appears when the historical mode's year falls inside the era its place's name applied. Overlays with different eras at the same physical spot need their own place records (one for the county-era name, one for the township-era one, say), since a place's date lives on its name, not a per-overlay field. Saving an overlay also fills in coordinates for any of its places that don't have any yet, using the center of whatever was drawn — so a place created just to hold a farm boundary or a route ends up located on the map without having to look up and enter its latitude/longitude by hand. When several places share one overlay this way, each gets spread out slightly around that center instead of landing on the exact same point, so they still separate into their own markers on the map rather than merging into one. It never overwrites coordinates a place already has. If markers ever do end up stacked on the same spot (nothing keeps two places from sharing coordinates by hand), clicking their combined number lists the places underneath so you can still pick one, rather than just zooming in on an empty-looking dot. Arriving on the map from a specific place (its own "Map" link, or a Wikidata-imported overlay) opens its detail card and overlay already showing, named on a chip in the header — clicking empty map to look around closes that card, and clicking the chip's label brings it right back without having to find the marker again.
• Look up a place on Wikidata. Adding a brand-new place first asks how you want to add it — manually, or from Wikidata — rather than mixing a "look up on Wikidata…" button in among the plain fields; picking Wikidata opens the search flow up front, and picking manual just goes straight to the usual fields. Editing an existing place still offers the Wikidata lookup as a plain enrichment button, since there's no such either/or to make there. Either way, searching by name and confirming a match fills in the place's coordinates and creates or links its whole enclosing hierarchy at once — city, county, state, country — each with its own coordinates, instead of creating and connecting every level by hand. A checkbox on that same confirmation screen (on by default) also fetches an outline from Wikidata, when one exists, for each newly-created level and for the place being added itself, so a state or country added this way shows its actual boundary on the map instead of just a pin — the same way a hand-drawn shape or historical map overlay does. Each outline is filled with a color: a hue per place type (country/state/county/city, etc., so every county reads as the same family next to a state's outline) shaded by the place's own Wikidata ID, so sibling places of the same type are still visually distinct from each other. The outline is labeled with the place's name, both in the overlay's own media description and in the Overlays panel's list, instead of showing up as an untitled region.
• A home person. Set a particular person as your own point of reference in the tree, which the Home page and some community add-ons build on. Opening the People list for the first time in a session starts with the home person selected (instead of the first row), unless you arrived with a specific person already chosen.

Editing

Clicking the edit button on any record opens its full editing form — a person, family, event, and so on — for changing that record's own details (a name, a date, a description) or its connections to other records, such as exactly how a child relates to their parents.

Creating a brand-new record of the type you're browsing (a new person, a new place, and so on) sits right next to that record's own Edit/Delete buttons, rather than in a separate spot above the list — so adding one and acting on the one you're already looking at are both in the same place.

For smaller, everyday changes, the "+" and "−" buttons are a shortcut: attach an existing citation, photo, or person without opening a full form, or remove one that's already linked. They only change what a record is connected to, not the record's own details. Each section's "+" sits right next to its heading (hover it to see what it adds, e.g. "Add a child"), so a record with mostly-empty sections stays compact. Tags are shown on their heading's line too, next to their own "+".

Not every field of every record type is editable yet — see Data Model and Editing for exactly what's covered today.

Duplicate records can be found and merged, too: select two records of the same type and choose Merge. See Data Model and Editing for how conflicts between the two are handled.

Community add-ons, written and editable in Python

Alongside the built-in features, there's a browsable catalog of small tools other people have written and shared — not limited to what the core developers built in. Browse it from inside the app, and install, update, or remove any of them with a click. Examples already in the catalog include relationship calculators, statistics, and custom lookups. See Gramplets and the Add-on Store for the full picture.

What makes these different from a typical plugin system is that each one is an actual Python program, and it runs right there in your browser, with nothing installed and no server involved. You can open any add-on's code from inside the app and edit it yourself: change how a chart looks, tweak what a lookup searches for, or write a new one from scratch. It's a real, working Python environment sitting inside a web page — genuinely unusual for genealogy software, where "customizing" normally means waiting for someone else to add the feature you want.

Some of these sit in a panel under a list and follow what you select there (View Gramplets); others you run from the Gramplets menu, where each opens in its own window, shows its progress, and can keep running minimized while you carry on working — several at once if you like.

Speed

Once you've looked at part of your tree, the app remembers it, so browsing, sorting, and searching feel instant afterward — even on trees with tens of thousands of people, where this kind of searching can otherwise take a very long time. See Architecture for how the local cache makes this possible.

Still growing

Gramps Connect is under active development, and there are things worth knowing aren't there yet — starting with finding and merging duplicate records. See Roadmap and Known Limitations for the fuller picture.

Part of the Gramps family

Gramps Connect reads and writes the same file formats as Gramps Desktop and gramps-web (GEDCOM and Gramps XML), so a tree can move freely between all of them.