Why does a GPX file fail to upload?

The short answer

Most upload failures come from the file not being what the receiving service expects, rather than from anything wrong with the coordinates inside it: a mismatched GPX version, a changed file extension, a file with no actual track in it, or a file that is empty or truncated. Checking each of those in order clears up the large majority of cases.

GPX 1.0 versus 1.1

GPX comes in two versions with different namespace declarations in the opening line of the XML, and a parser built strictly around one can refuse a file written to the other. GPX 1.1 is the modern, more widely supported version; most current tools export and expect it, but older files, or ones written by less common tools, can still be 1.0. The two look almost identical to a human reading the file and behave completely differently to a strict parser checking the header.

The version is declared once, right at the top of the file, in the opening <gpx> tag — worth a glance if a specific service refuses a file that opens fine everywhere else.

The extension changed without anyone meaning it to

A GPX file is plain XML text, and that is exactly the problem: some email clients and messaging apps rewrite an attached .gpx file as .xml or .txt on the way through, because to them it just looks like text. The upload form on the receiving site checks the extension, sees something other than .gpx, and refuses it before ever reading the contents. Renaming the extension back to .gpx, without touching anything inside the file, is enough to fix this specific case.

A file with no track in it

GPX can describe three different things: a track (a timestamped recording of where you actually went), a route (a planned sequence of points to head towards, no timestamps), and standalone waypoints (individual pinned locations). A service built around uploading an activity generally expects a track. A file that only contains a route or a scattering of waypoints — which happens when a file comes from a planning tool rather than a recorder — can be accepted as a different kind of upload, rejected outright, or imported as something unrecognisable, depending on how strict the site is.

A few other causes worth ruling out

• A zero-byte or partial file — an export interrupted by a dropped connection or a phone that went to sleep mid-transfer can leave a file that looks present in Files but has nothing readable inside it.
• Malformed XML from hand-editing — an unclosed tag, or a character like & typed into a name without escaping it, is enough to make an entire file invalid even though only one line was touched.
• An upload size limit — a file combining an entire recorded history rather than one route can run large enough to hit a cap that a single day's track never would.
• The wrong file entirely — GPX, KML and TCX all describe route data but are structurally different formats; a site expecting one will refuse the others outright rather than trying to read them.

How to narrow it down

Open the file in a plain text editor and check two things: the version number in the opening <gpx> tag, and whether the body actually contains a <trk> element with track points inside it, rather than only <rte> or <wpt> entries. Between those two checks and a look at the file size, most rejections turn out to have an obvious cause once you know where to look, rather than requiring the file to be rebuilt from scratch.

Where TrailCam fits in

TrailCam exports GPX 1.1, which is what the mapping and activity services that read GPX at all are generally built around today, for a single route or your whole history at once. Export is part of the optional TrailCam Pro upgrade; the app itself is free to download.