Does FamilySearch give a specific reason when an upload fails?

Rarely. Most failures surface as a generic rejection, an indefinite processing state, or a vague success message like "some records were not uploaded correctly" — none of which point to a specific cause on their own.

Is there a way to get a specific diagnosis instead of a generic error?

Yes — run the file through the Upload Readiness Checker before you upload. It parses the file locally and checks it against the same size, count, and structural patterns behind these error states, so you get a specific answer instead of guessing after the fact.

My upload didn't show any error at all — is that actually a problem?

It can be. A completed upload with no error message is exactly what silent data loss looks like — the safest check is comparing your individual count before and after, not just watching for an error to appear.

Common GEDCOM Upload Error Messages, Explained

From outright rejection to indefinite processing to silent data loss, here's what each FamilySearch GEDCOM upload failure actually means and what to do.

GEDCOM Fix Editorial TeamUpdated August 26, 20263 min read

FamilySearch's GEDCOM importer doesn't give detailed error messages the way a desktop application does. What you get instead is one of a small number of vague states, each of which maps to a specific, identifiable cause once you know what to look for.

"Upload failed" / the file won't upload at all

This is almost always size-related. FamilySearch's Help Center documents a hard 100 MB cap on GEDCOM uploads — one user reported being unable to upload a 107 MB file, just a few megabytes over that line. If your file won't upload at all and you haven't seen any specific reason why, check its size first; it's the one limit FamilySearch states as an actual technical ceiling, not a soft recommendation.

The upload sits at "processing" indefinitely

This is a hang, not a rejection — the file was accepted, but the import never resolves. It isn't limited to huge files: one user reported a file just 31.6 MB in size stuck for four days, completing only "half way," with no error and no estimated time to finish. There's no published expected duration for a normal upload, so a stuck spinner can't be distinguished from a slow-but-working import just by watching it. See How Long Should a GEDCOM Upload Take? for what to actually do if this happens to you.

"Some records were not uploaded correctly"

This is the most specific-sounding message FamilySearch actually shows, and it's still vague — it tells you something didn't come through, not what or why. It's been reported on files around 1,000 individuals and larger. We cover this exact message in detail in its own dedicated guide, since it's specific enough to search for and common enough to deserve one.

The upload "succeeds" with no error, but people are missing

This is silent data loss, and it's the pattern with no error message at all — which makes it the easiest one to miss. One user uploading a file with over 2,500 individuals ended up seeing only themselves and one other family member afterward, with nothing in the interface flagging that anything had gone wrong. If you've uploaded a large file, don't just check for an error — check that your actual individual count matches what you expected.

What all four have in common

None of these four states tell you why on their own. They're symptoms of the same small set of underlying causes: file size, individual count, and structural issues inside the file (broken references, malformed records, or an encoding mismatch that garbles names — see GEDCOM Encoding Problems if that's what you're seeing). That's the gap the Upload Readiness Checker is built to close — it parses your file locally in your browser and tells you specifically which of these patterns your file matches before you ever click upload, rather than after you've already lost time waiting for one of these four vague outcomes.

Why FamilySearch doesn't say more

This isn't an oversight so much as a structural limitation of how the import works: FamilySearch's compare-and-add process matches your file's individuals against records that may already exist in Family Tree, one at a time, and a mismatch, conflict, or malformed entry anywhere in that process tends to surface as a generic state rather than a line-by-line error report. A desktop GEDCOM validator can point at the exact line and tag that's malformed because it never has to reconcile your file against millions of other people's data — FamilySearch's importer is solving a fundamentally harder matching problem, and the tradeoff is a much vaguer failure mode when something goes wrong.

What to do before you try again

If you've hit any of these four states, don't just retry the same upload — check size and individual count first (the FamilySearch GEDCOM Size and Individual Limits guide has the exact numbers), then check encoding if names looked wrong even before uploading. If your file is large or complex enough to be a plausible cause, splitting it into a smaller, targeted export — see How to Split a Large Family Tree Before Uploading — resolves the majority of cases reported in FamilySearch's own community forum, regardless of which of the four messages you saw.

Do it now

Find out which of these applies to your file

Keep reading

Understanding GEDCOM's Level/Tag/Value Structure

Common questions

Does FamilySearch give a specific reason when an upload fails?: Rarely. Most failures surface as a generic rejection, an indefinite processing state, or a vague success message like "some records were not uploaded correctly" — none of which point to a specific cause on their own.
Is there a way to get a specific diagnosis instead of a generic error?: Yes — run the file through the Upload Readiness Checker before you upload. It parses the file locally and checks it against the same size, count, and structural patterns behind these error states, so you get a specific answer instead of guessing after the fact.
My upload didn't show any error at all — is that actually a problem?: It can be. A completed upload with no error message is exactly what silent data loss looks like — the safest check is comparing your individual count before and after, not just watching for an error to appear.