The GPX format explained: tracks, waypoints, extensions and what your watch writes

A GPX document has a single <gpx> root element carrying a version and a creator attribute. Inside it, the 1.1 schema expects a fixed order: an optional <metadata> block, then any number of waypoints (<wpt>), then routes (<rte>), then tracks (<trk>), then extensions. Most readers are forgiving about that order; validators are not.

The three geometry types mean different things. A waypoint is a single named place — a hut, a water tap, a trailhead. A route is a planned sequence you intend to follow, where each <rtept> is normally a decision point rather than a recorded position. A track is what actually happened: a <trk> holds one or more <trkseg> segments, and each segment is a list of <trkpt> in time order.

Segments exist to express breaks. When a device loses its fix, is paused or is switched off and on again, the correct representation is a new <trkseg> rather than a straight line across the gap. Cleaning tools use the same mechanism: deleting points from the middle of a track means splitting one segment into two.

A <trkpt> carries latitude and longitude as attributes, in decimal degrees on WGS84, and everything else as child elements. The number of decimal places is a direct statement of precision: six decimals is about 0.11 m of latitude, five is roughly 1.1 m, four about 11 m and three about 111 m. A degree of longitude narrows with the cosine of the latitude, so at 60° north it is only half as wide as at the equator.

Watches routinely write six or seven decimals, far beyond the real accuracy of consumer GNSS, which on a good day is two to five metres. The extra digits do not make the file more accurate. They do make it look precise, and they preserve the exact value of a point that happened to be inside your garden.

<ele> is elevation in metres. The specification defines it as height above the WGS84 ellipsoid, but most devices write something closer to height above mean sea level, which is why elevation figures from two brands rarely agree. <time> is the moment of the fix, and <extensions> is where everything the format never anticipated ends up.

The <time> element is an xsd:dateTime and in practice always ends in Z: 2026-06-11T04:12:00Z. GPX has no time-zone field anywhere, so local time has to be inferred from the coordinates. A reader that shows you “07:12” is applying a zone it guessed from the position.

That has a specific privacy consequence: because the coordinates disclose the zone, removing the date while keeping the coordinates still allows the local time of day to be reconstructed. Shifting timestamps to another date also keeps the time of day intact unless you change it deliberately.

A file with no <time> elements at all is still valid GPX. It simply stops being an activity: there is no duration and no pace to compute, so platforms treat it as a route or a course.

GPX 1.1 allows any element inside <extensions>, and conforming readers must ignore what they do not recognise. That is how heart rate ended up in a format with no heart-rate field. The de-facto standard is Garmin's TrackPointExtension, namespace http://www.garmin.com/xmlschemas/TrackPointExtension/v1, which defines <hr>, <cad>, <atemp>, <wtemp> and <depth>.

Power lives in a separate Garmin namespace, PowerExtension, as <PowerInWatts>; some applications write a bare <power> element instead. Strava, Komoot and others each add their own, and it is normal to see two or three namespaces declared on the root element of a single file.

Extensions are where the sensor data lives, and they are the easiest thing to remove safely: since readers must ignore unknown extensions, deleting them cannot break a file. What you lose is the training data — heart rate, cadence, power, temperature — not the route.

The optional <metadata> block holds a name, a description, keywords, a timestamp and an <author>. The author's email is split across two attributes — <email id="someone" domain="example.com"> — an anti-scraping habit from 2004 that still reassembles into a working address in one step.

<link> elements often point back at the activity on the platform that exported the file, which means the file identifies the account it came from even after you rename it. The creator attribute on the root element names the device or application that wrote it: an exact watch model, or an app and its version.

Waypoints deserve separate attention. Their coordinates are no worse than the track's, but their <name> elements are written by people — Home, Office, Mum's — and a name is a label a stranger does not have to infer.

Removing things is safe. A track point needs only its lat and lon attributes; <ele>, <time> and <extensions> are all optional, and a <trkpt> with no children at all is legal. Deleting whole waypoints, routes or the entire metadata block is equally fine.

What does break files: an unclosed tag, a raw ampersand inside a name, coordinates outside ±90 and ±180, and a namespace prefix that is used but never declared. GPX 1.0 (namespace .../GPX/1/0) puts some elements in different places, so a strict 1.1 validator rejects a 1.0 file — though most software reads both.

Platforms add rules of their own on top of the schema: a maximum number of points, a requirement that timestamps increase, or a minimum distance before an upload counts. When an upload is refused and the file validates cleanly, those platform rules are usually the reason.