What is the extensions element in a GPX file?
Extensions is an optional block inside a GPX file, sitting alongside a track point, a route, or the file as a whole, reserved for whatever a specific device or piece of software wants to attach that the GPX schema itself has no defined field for. Nothing about it is standardised beyond its existence as a container — what actually goes inside is decided entirely by whoever wrote the file, which is exactly why it behaves so differently from the rest of a GPX file once that file leaves the program that created it.
The short answer
GPX 1.1 defines a fixed, published list of fields a track point is allowed to carry — position, elevation, a timestamp, and a handful of others such as a name or a fix type. That list was closed off deliberately, because a format meant to move between many different pieces of software needs every reader to agree on what a given field means. Extensions is the one part of the schema left open on purpose: a labelled container where a device or app can put additional data of its own choosing, without having to ask the format's maintainers to add a new official field first.
What the standard fields don't leave room for
A track point's core fields cover where you were, how high up, and when — the three things almost every GPS use case needs, and the three things GPX has carried since it was first published. Plenty of hardware and software wants to record more than that against a single point: a reading from a sensor built into a particular device, an internal quality flag a specific app uses to judge one fix against another, or an identifier that only makes sense to the program that wrote it. None of that has an official slot in the schema, because the schema was fixed once and could not keep growing a new field every time one manufacturer wanted to log one more thing.
What actually ends up inside one
In practice, an extensions block holds whatever the software that wrote it decided was worth keeping. A weather-capable outdoor device might log an ambient reading alongside a point. A particular app might tag a point with an internal accuracy code it uses to draw a confidence colour on its own map. A website that lets you re-upload a route might embed a private reference number so it can match the file back to an account if you send it in again later. None of these examples are official GPX fields — each one lives inside a namespace that belongs to whoever invented it, bolted onto the point rather than built into the format itself.
Why extensions don't travel well between apps
This is the part that catches people out. A GPX reader is only obligated to understand the core schema; anything inside an extensions block written under a namespace it does not recognise, it is free to simply skip over. That is not a bug in the receiving app — ignoring unknown extensions gracefully is exactly what a well-behaved GPX reader is supposed to do, so that one company's private additions never stop a completely different program from reading the position, elevation and time that everyone agrees on. The practical effect is that a number sitting inside an extensions block can look perfectly normal in the app that wrote it and simply vanish the moment the same file is opened somewhere else, with nothing about the file itself being broken.
That also means extensions is a poor place to look for anything you actually need to survive a move between tools. If a number matters enough that you want it in Strava, Garmin Connect, Komoot and a spreadsheet alike, it needs to live in a field every one of those readers already agrees on, not in a container that only the app which wrote it is guaranteed to open back up correctly.
Where TrailCam fits in
A route exported from TrailCam is a plain GPX 1.1 file: track points carrying position, elevation and time, the fields every reader already knows how to open, without a private extensions block that only round-trips correctly through TrailCam itself. That is a deliberate trade — nothing proprietary is attached that another app would have to recognise and might silently drop — so the file behaves the same way wherever it ends up. GPX export is part of the optional TrailCam Pro upgrade; the app itself is free to download.
Questions
- Does every GPX file have an extensions block?
- No. It is entirely optional, and a plain track export with nothing beyond position, elevation and time simply has no reason to include one.
- Is it safe to delete an extensions block from a GPX file?
- For the core track, yes — position, elevation and time live in separate fields of their own, so removing an extensions block leaves them untouched. You would only lose whatever app- or device-specific data was stored inside that block.
- Why did a number I saw in one app disappear when I opened the same file in another?
- It was very likely stored inside an extensions block written under that first app's own namespace. A different reader is allowed to skip data it does not recognise rather than guess at what it means, so anything kept only in extensions can look present in one place and be gone in another.
Recording your own routes
TrailCam is an iPhone app that records your route with GPS, keeps video clips, photos and voice notes pinned to the spot where you took them, and exports the result as GPX 1.1 or CSV. It is free to download.