What Is GEDZIP, and Why Does It Matter for Photos?

If you've ever moved a family tree between programs and had every photo reference turn into a broken link, GEDZIP is the fix GEDCOM 7.0 introduced for exactly that problem.

The problem GEDZIP solves

In GEDCOM 5.5.1, a photo or document attached to a person isn't stored inside the GEDCOM file itself — it's referenced by a file path or link pointing to wherever the image lived on the computer that created the export. That reference travels fine within the same computer, but the moment the .ged file moves anywhere else — a different computer, a different program, a shared drive with a different folder structure — the path breaks. The GEDCOM data still says "photo attached," but nothing can find it anymore. This is the mechanism behind why photos go missing when a GEDCOM file changes hands, and it's been a recurring complaint for as long as genealogists have shared files between programs.

How GEDZIP fixes it

GEDZIP is a container format introduced alongside the GEDCOM 7.0 specification. Instead of a bare .ged text file with external references, a GEDZIP package is a standard zip archive containing the GEDCOM data itself plus the actual media files it references, organized in a defined internal structure so any GEDCOM 7.0-compliant program knows exactly where to look inside the archive. The practical effect: a photo attached to an individual travels with the file, not alongside it as a separate, easily-detached reference.

What's actually inside one

A GEDZIP file (typically with a .gdz extension) is, structurally, just a zip file — you could technically open it with any standard archive tool. Inside, it holds the GEDCOM 7.0 data file plus a media directory containing the referenced photos and documents, linked internally using relative paths that stay valid regardless of where the whole package ends up. This is a meaningful shift from 5.5.1's approach, where the media reference and the media file were never actually bundled together in the first place.

Does bundling media affect upload size limits?

Yes, and this is worth planning for. A bare .ged text file is almost always small — even a tree with tens of thousands of individuals is typically just a few megabytes of plain text. Once photos and documents are bundled inside a GEDZIP package, the file size is driven by media, not genealogical data, and can grow far larger, far faster. If you're preparing a file for a platform with a documented size cap — FamilySearch's is 100 MB — a GEDZIP export with a modest set of high-resolution photos can hit that ceiling well before the underlying tree data would on its own. Check whether your target platform accepts GEDZIP at all before relying on it for a large media-heavy tree; many current import pipelines still expect a plain .ged file.

What this means for you

If your genealogy software supports GEDCOM 7.0 and offers a GEDZIP export option, using it is the more reliable way to share a tree that includes photos — the recipient gets everything in one file instead of a .ged file plus a separate folder of images they have to keep track of and place correctly. See Does My Genealogy Software Support GEDCOM 7.0? to check whether your specific program offers this, since GEDZIP support tracks GEDCOM 7.0 support generally and isn't universal yet.

If you're still working with GEDCOM 5.5.1 files and media attachments, the safest workaround is manually keeping the referenced image files together with the .ged file in the same relative folder structure whenever you move or share it — not a guarantee, but it reduces the chance of a broken reference compared to moving the .ged file alone.