gpx.studio: a browser GPX editor with the map doing the work

Two packages in one repository, and only one of them is a dependency

The repository contains the source code of the website, and the code is split into two parts. The gpx directory is a TypeScript library for parsing and manipulating GPX files. The website directory is the website itself, which is a SvelteKit application.

That split is the single most important architectural fact about the project, and it is easy to miss because the repository name and the product name are the same. gpx.studio is the online tool. gpx is a library. If you want to read, edit or write GPX data in your own code, the library is what you would install, and the website is a consumer of it rather than the other way around.

The top level listing reflects that: .github, .gitignore, a prettierignore and prettierrc, a .vscode directory, LICENSE, README.md, crowdin.yml, and then the gpx and website directories. There is no monorepo tooling visible in the root, and the README's own build instructions treat the two parts as separate steps, one after the other.

The website, on the other hand, is the part most people will actually use, and it is a serious application rather than a demo. The interface screenshot in the README shows a full editor with a map, and the credits list names a charting library, a routing engine, a sortable file tree and an IndexedDB wrapper, which is the dependency list of a real tool.

The other structural point is the documentation. The site is a SvelteKit application and the docs are written in Markdown and rendered with MDsveX, and the search is Algolia DocSearch. So the documentation lives inside the same project and uses the same toolchain.

The map is the editor, not a picture next to it

What separates gpx.studio from a text editor for XML is the interaction model. The map is the primary surface, and the file tree, the charts and the property panels are attached to it.

The mapping stack in the credits explains why. MapLibre GL JS provides beautiful and fast interactive map rendering, and the map data comes from OpenStreetMap, which the credits describe as open map data used by most of the map layers and by the routing engine. On top of that, Mapterhorn supplies high-quality open terrain data used by some map layers, including for 3D, and also by the routing engine.

So the terrain data is not decoration. It is the elevation source, which is what makes a 3D profile and a meaningful distance reading possible, and it feeds the same routing engine.

That routing engine is GraphHopper. A GPX editor that can snap a drawn line to a real path, or compute a route between two points on a map, needs a routing backend, and the project uses an open one rather than a hosted API.

The result is an editor where the geometric and the descriptive data live together. You see the track and the waypoints on a map, you see the elevation profile, you see the list of points, and you edit them in the same view. That is the reason the project calls itself an online GPX file editor rather than a viewer.

Building the library, then running the site with your own map key

You need Node.js to build and run both parts, and the README gives the two sequences separately.

The gpx library is built first, in its own directory.

cd gpx
npm install
npm run build

The website has one extra step, and it is the step that trips people up. To be able to load the map, you need to create your own MapTiler key and store it in a .env file in the website directory.

cd website
echo PUBLIC_MAPTILER_KEY={YOUR_MAPTILER_KEY} >> .env
npm install
npm run dev

The variable name is the important detail, because the PUBLIC_ prefix is a SvelteKit convention that means the value is exposed to the browser. A map tile key has to be visible to the client, so it cannot be a server secret, and the practical consequence is that anyone can read yours from the page source or the network traffic. That is normal for a tile key, and it is why the key is tied to your own MapTiler account rather than shipped with the project.

What this tells you about running the project is that a local development setup is not self contained. There is no offline mode and no bundled tile source. To see a map you need a MapTiler account, a key, and a network connection. For a public deployment the same applies, and the credit line in the README shows the project hosts its own instance at gpx.studio, so the maintainer is running the same arrangement.

Client side state with Immer, Dexie and a sortable file tree

The logic dependencies describe what kind of application this is, and they are all client side.

Dexie.js is an IndexedDB wrapper, so the user's files live in the browser's local database rather than being uploaded to a server. Immer is listed for complex state management, which in practice means the editor holds a document tree and derives new versions of it without mutating in place. SortableJS creates a sortable file tree, which is how a GPX project with multiple files and folders is reorganised by dragging.

Chart.js draws the charts. fast-xml-parser is listed for fast GPX file parsing, which matters because a long track with thousands of points is a large XML document and parsing it on the main thread is where an editor like this either feels instant or feels broken. The gpx library is the TypeScript layer for parsing and manipulating GPX files, and fast-xml-parser is the fast path underneath it.

Putting these together, the data flow is: a GPX file is parsed into a document tree, the tree is held in state, the map renders the geometry from that state, the charts render the elevation and distance series from it, and every change writes back through the library and into IndexedDB.

The design is coherent, and the important consequence is privacy and offline behaviour. Because the storage is IndexedDB and there is no server component mentioned for the document data, the file you are editing does not leave the browser. What does leave the browser is the map tile requests, which go to the tile provider, and the routing calls.

Translations run through Crowdin, and contributions start with an issue

Two community processes are documented, and both are worth reading because they tell you how a change actually gets in.

Translations are handled by volunteers on a collaborative translation platform, and the Crowdin project is linked from the README. If you want to start a translation in a new language, you are asked to contact the maintainer or create an issue first, rather than just opening a pull request with a new set of strings. The crowdin.yml file at the repository root is the configuration for that flow.

Contributions have a similar shape. Bug reports and feature requests go to the issue tracker. Code contributions are welcome, but except for obvious bug fixes, you are asked to open an issue first to discuss the changes you would like to make.

That is a maintainer protecting their time rather than a gate against contributors, and for a project with a single obvious maintainer it is a sensible rule. It does mean the contribution loop is issue first, then pull request, and a reviewer who is one person.

The MIT license is stated plainly, with a LICENSE file at the root. For a tool that runs entirely in the browser, MIT is the right choice, and it means you can take the gpx library into a commercial product without the copyleft obligations that would come with a reciprocal licence.

Where the browser boundary becomes a real constraint

There are limits to this model, and they are worth naming because they are not the usual ones.

The first is that the editor is bound by what a browser can hold. Dexie and IndexedDB give you a local database, but a very long track with a dense set of tracks, waypoints, routes and extensions can still push the limits of what is comfortable to parse and re-render in a page. The library's job is to keep that manageable, and the fast-xml-parser dependency suggests the author was thinking about it, but the ceiling is the browser rather than a native application.

The second is that you need a tile provider to see anything. A local development setup requires a MapTiler account and key, and the PUBLIC_ prefix on the variable means that key is visible to anyone using the deployment. For a private tool on a company network that is usually fine and for a public one it is normal practice, but it does mean a keyless deployment is not a supported configuration.

The third is the routing dependency. GraphHopper does the route computation, and OpenStreetMap and Mapterhorn provide the data. That is a good trade for a tool that runs without a paid API account, and it also means the routing results depend on the quality of open data, which varies by region, and that a deployment which needs guaranteed routing coverage has to look at the underlying data rather than at the editor.

And the fourth is the one to keep in mind when choosing this over a desktop tool. The application is a website, so it wants a network to load its code and its tiles, even though the document data stays local. A field tool with no connectivity is a poor fit.

Editorial conclusion

gpx.studio fits someone editing GPX files who wants a map, a file tree, charts and routing in one browser tab rather than a text editor and a converter script, and it fits developers who want to reuse the standalone gpx library for parsing and manipulating GPX in their own TypeScript project. It does not fit a workflow that must keep the data on a machine with no network access, and it does not fit a team that expects the site to be self hostable without a tile provider account. Check three things before you commit. Check whether the gpx library alone solves your problem, since it is a separate package with its own build step and it is the part you can actually depend on. Check the map key, because running the site locally needs your own MapTiler key in a.env file in the website directory, stored as PUBLIC_MAPTILER_KEY, so it is a public variable and a registered account rather than a self contained build. And check what the routing does with your data, because GraphHopper and OpenStreetMap are doing the work and your tracks pass through them. The last push was on 2026-10-18, the repository has no GitHub releases, and the license is MIT.

Frequently asked questions

Official sources

1. gpxstudio/gpx.studio on GitHub
2. Issues
3. License: MIT
4. Project website
5. README