How to Fix a Corrupted GPX File

How to Fix a Corrupted GPX File (Quick Answer)

To fix a corrupted GPX file, run it through a GPX validator to locate the exact error, apply the automatic repairs it offers, then hand-edit whatever remains in a plain-text editor: delete the truncated trackpoint at the end of the file, close any unclosed tags, and confirm the file starts with an <?xml?> declaration and a <gpx> root element. Because GPX is plain XML text, most damaged files are fully recoverable in a few minutes.

1. Make a backup copy of the corrupted .gpx file before touching it, so every repair attempt starts from the same original.
2. Run it through the GPX Validator — it runs locally in your browser (nothing uploads) and lists every error and warning it finds.
3. Apply the automatic repair. The validator fixes what it can on its own: it inserts a missing GPX namespace, version, or creator attribute on the root element and fills empty <name> elements.
4. Fix remaining errors in a text editor — delete a truncated trackpoint at the end of the file, close unclosed tags, escape stray & and < characters, and remove points with out-of-range coordinates (see the fixes below).
5. Re-validate and test: run the repaired file through the validator again, then open it in your mapping app to confirm the track draws correctly.

Step 1: Diagnose with the GPX Validator

Guessing at XML errors wastes time; a validator tells you exactly what is broken and where. The free GPX Validator parses the file in your browser and reports every problem it finds, including:

• A missing or wrong root element (the file must be wrapped in <gpx>…</gpx>)
• Missing version, creator, or xmlns namespace attributes — and version/namespace mismatches (e.g. a file that declares GPX 1.1 but uses the 1.0 namespace)
• Latitude outside ±90° or longitude outside ±180°, and coordinate values that aren't valid numbers at all
• Non-numeric elevation values and unparseable or out-of-chronological-order timestamps
• Points stuck at latitude 0, longitude 0 ("null island") — a classic sign of GPS dropouts during recording
• Empty tracks, empty segments, and missing names

Its auto-repair is deliberately minimal and never discards data: it only inserts missing root attributes (namespace, version, creator) and fills empty name elements, leaving everything else in the file untouched. Anything beyond that — the interesting breakage — is a manual fix.

Manual XML Fixes for the Common Breakages

1. Truncated file (recorder died mid-write)

The most common corruption by far: the device or app lost power while writing, so the file simply stops mid-trackpoint and the closing tags never got written. Scroll to the very end of the file, delete the incomplete final <trkpt>, and append the closing sequence:

      </trkpt>   <!-- end of the last COMPLETE point -->
    </trkseg>
  </trk>
</gpx>

You lose one trackpoint; the rest of the recording is intact. For reference, a minimal valid GPX 1.1 file looks like this (root attributes per the Topografix GPX 1.1 schema):

<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.1" creator="YourApp"
     xmlns="http://www.topografix.com/GPX/1/1">
  <trk>
    <name>Track Name</name>
    <trkseg>
      <trkpt lat="34.0522" lon="-118.2437">
        <ele>89.0</ele>
        <time>2026-07-07T08:15:00Z</time>
      </trkpt>
    </trkseg>
  </trk>
</gpx>

2. Unescaped special characters

XML reserves & and <, so a waypoint named "Ridge & Saddle" written without escaping breaks the whole file at that line (per the W3C XML specification). Search the file for a bare & and replace it with &; replace a stray < inside text with <.

3. Encoding problems

A file that declares encoding="UTF-8" but was saved in another encoding (or picked up junk bytes during a bad transfer) fails to parse even though it looks fine. Open it in an editor that shows the encoding, re-save as UTF-8, and delete any garbage characters — they usually cluster at the point where a transfer was interrupted.

4. Out-of-range or (0, 0) coordinates

Latitude must sit within ±90 and longitude within ±180; values outside that range, or points recorded at exactly 0, 0 during a GPS dropout, put trackpoints in the wrong hemisphere or the Atlantic Ocean. Delete the offending <trkpt> elements — the validator's report tells you exactly which point numbers to look for.

How Corruption Shows Up

A corrupted GPX file usually announces itself in one of four ways: the file refuses to open at all (malformed XML), the track draws but stops early (truncation), points appear in absurd locations (bad coordinates), or the app throws a parse error naming a specific line. Matching the symptom to the fix above saves a lot of trial and error.

Why GPX Files Get Corrupted

Nearly all GPX corruption comes from an interrupted write or transfer: the recording device lost power mid-save, a crash stopped the app before it closed the file, or a copy between devices was cut short. Hand-editing is the other frequent culprit — one deleted angle bracket is enough to make a parser reject the entire file. Actual disk-level damage is rare.

Preventing the Next One

Prevention is mostly about letting writes finish: stop the recording and give the app a moment to save before powering off, eject or safely disconnect devices before pulling the cable, and validate files right after export instead of the night before a trip. Keep the original file whenever you edit — repairs are easy when you can always return to a known starting point.

When the Data Is Really Gone

Related Tools and Resources