Editorial policy

viewmygpx is written and reviewed by the same small group of off-road hikers and cyclists who use the tool. The site exists because we wanted a GPX viewer and converter that wasn't cluttered with upsells and didn't make our routes pass through somebody else's server. The same standard applies to the writing on the site: it is the documentation we wished other sites had written when we were trying to figure out why a file wouldn't import or what a particular extension was for.

This page documents the editorial standards: how we choose what to cover, how we cite, how a draft becomes a published page, how AI fits in, how we handle conflicts of interest and corrections, and what we will and won't do under pressure. The companion page, methodology, describes the research and testing process; this page describes the editorial standards that govern publication.

What we cover and why

The site is scoped to GPX files: the format itself, the tools that produce them, the platforms that consume them, the conversions to and from related formats, and the practical work of getting your route from one place to another. We don't cover gear reviews, race-by-race trail reports, fitness training plans, or destination guides. Plenty of other sites do those well; we don't add anything by piling on.

Within that scope, we prioritize the questions our readers actually run into. Format pages cover the parts of GPX that real files contain. Platform pages cover the integrations our readers use. Converter pages cover the format pairs that show up in real export chains. We don't publish a page just to claim a keyword.

Writing principles

Direct answers first. The first 50 words of every page answer the search query in plain prose. No throat-clearing openings, no "in this guide we'll explore" setups. A reader who lands on the page mid-task gets the answer in the first paragraph and can leave; readers who want the full picture keep going.
Cite primary sources inline, not at the bottom. Technical claims about a format link to the format's spec. Claims about how a platform behaves link to the platform's own documentation. The link sits next to the claim, where it can be checked, not in a footnote. The full hierarchy of what counts as a primary source is documented on the methodology page.
Use the same voice across the site. Three sentences per paragraph or fewer. No marketing fluff. No banned phrases ("unleash," "effortlessly," "game-changer," "seamlessly"). The short version of the voice rule: documentation written by people who actually use the thing, not copy written for people who haven't used it yet.
Numbers in prose, not as decoration. Sample sizes, field counts, file sizes appear in the sentence: "the file contains 2,847 trackpoints," not "2,847 trackpoints!" on its own line.
Update on real triggers, not on a schedule. When a platform changes its UI, a spec gains a revision, or a reader flags a step that no longer matches reality, the affected page is reviewed and revised. We don't add a fake "updated this month" banner to make pages look fresh.
No invented anecdotes. Examples are either real (an actual file, an actual platform behavior we observed) or generic and labeled as such. We don't invent stories about riders or hikers to sell a point.
Don't bury the answer. Every page has a structure that lets a reader scan to the section they need. Long pages exist because the topic is genuinely long; we don't inflate length to look comprehensive.

Sourcing

Every factual claim on the site links to its canonical primary source. The hierarchy is documented in detail at /methodology/; the editorial consequence of the hierarchy is the rule we apply at the page level: claims that can't be supported by a source at the appropriate level get rewritten or cut. We don't publish "some users have reported that..." or "it has been observed that..." — those are guesses dressed as evidence.

Where the spec is silent and the platforms vary, we say so explicitly. "The GPX 1.1 spec does not require timestamps to be in UTC; in practice, most modern devices write UTC with a Z suffix, while some legacy desktop tools write local time without a time zone" is a more honest sentence than "timestamps should be in UTC." The ambiguity in the world should be visible in the writing, not papered over.

Authorship and voice

Pages on viewmygpx are published under the collective voice of the site rather than under named bylines. We are a small group of off-road hikers and cyclists running the site in our spare time; the "we" in our prose is literally us. We don't invent personas, we don't fabricate author bios, and we don't adopt fictional credentials to look more authoritative.

The collective voice is a deliberate choice. Naming individual writers on a small site of this scope creates pressure to inflate bios and credentials; using the collective voice keeps the focus on the work. The accountability is collective: every published page has been read by at least two of us before it went live, and the editorial standards on this page apply to every page on the site.

Review process

Drafts are reviewed by a second person before they are published. The reviewer's job is concrete:

Catch factual errors against the source-of-truth hierarchy.
Click every external link, confirm it resolves to the document we're citing, and confirm the cited document still says what we claim.
Independently run any "how to" steps on a real account and confirm the steps match the platform's current UI.
Verify that any claims about file structure, parser behavior, or converter output are reproducible against the test corpus.
Read the writing for clarity, voice, and structure. Buried answers, throat-clearing openings, and marketing-flavored phrasing are flagged.

We don't ship a guide that nobody but the writer has verified. That rule applies even when the writer is the most experienced person on the topic — second eyes catch what first eyes don't. When the reviewer disagrees with the writer on a substantive question (which interpretation of a spec is correct, which platform behavior is the common case), the disagreement is resolved by going back to the source-of-truth hierarchy together, not by overruling.

AI use disclosure

AI tools are part of the research and drafting process at viewmygpx. To be specific about how:

Research summarization. AI is useful for pulling long platform-documentation pages, multiple help-center articles, and our own previous research notes into a single working document we can read end-to-end. The AI summarization is an input to our work; the citations in the published page link to the original sources, not to the summary.
Outline and structure. AI is useful for generating a first-draft outline that we can rearrange or discard. The choice of which sections appear in the final page is ours.
Drafting paragraphs. AI sometimes drafts a first version of a paragraph that we then rewrite. The rewrite is the version that ships; an AI-generated paragraph in its raw form is not the published version of the page.
Code-review-style critique. AI is useful for reading our own drafts back to us with a checklist (banned phrases, voice consistency, source coverage). It catches obvious misses before the human reviewer sees the draft.
Alt-text candidates. AI generates first-draft alt-text for images, which a human reviewer edits or replaces before publication.

What AI is not used for, and will not be used for:

Fabricating sources. Citations on viewmygpx are to documents we have read and confirmed. AI is well known to generate plausible-looking citations that do not exist; that is one of the failure modes the source-of-truth hierarchy on the methodology page is designed to catch.
Asserting platform behavior. Claims about how a platform handles a GPX file come from a real test on a real account, not from AI inference about what the platform probably does.
Generating images of routes or trails. Images on the site are screenshots from the tool, photographs of real places, or schematic illustrations. We don't use AI-generated images of trails, riders, or any specific terrain.
Bypassing the review process. Every page is reviewed by a human regardless of how much of the draft text originated with AI.

We don't mark individual paragraphs as "AI-assisted" or "human-written" because the workflow is mixed throughout — most pages have AI-touched and human-only paragraphs side by side. The editorial responsibility for every published sentence is ours, regardless of where the first draft came from.

Conflict of interest disclosure

viewmygpx is funded out of pocket today. The long-term plan is to support the site through display advertising on guide pages — never on the viewer, editor, or converters. The mechanics and boundaries of that plan are documented on the about page.

Editorial decisions are not influenced by potential or actual revenue. To be specific:

No paid placements. No platform pays us to recommend it. No vendor pays for editorial coverage. If a platform sales rep approaches us with a paid-placement offer, the answer is no, and the offer does not affect how we write about that platform.
No sponsored content. "Sponsored," "in partnership with," "presented by" — none of these structures appear on viewmygpx. If we ever do sponsored content (we don't plan to), it will be clearly labeled and structurally separated from editorial pages.
No affiliate-driven recommendations. If affiliate links appear in the future for gear or services we actually use, they will be clearly disclosed inline at the link. We will never recommend a product because of an affiliate relationship; the editorial choice comes first, and any affiliate revenue follows from products we would have recommended anyway. No affiliate links are live on the site today.
No platform vetoes. No platform we cover has editorial input into our coverage of them. We don't share drafts with platforms before publication, we don't send courtesy copies for vetting, and we don't accept changes requested by a platform unless the change is a factual correction supported by a primary source.

Display advertising, when introduced, will sit in clearly demarcated slots and never replace, prefix, or interrupt editorial content. Ad creative is not editorial. We do not write ad copy and we do not select advertisers; an ad network handles inventory, with our instructions on category exclusions.

Corrections policy

Factual corrections are treated as bugs. The process:

A correction comes in (most often by email, sometimes from our own routine spot-check, occasionally from a platform release note or a peer site).
The page is reviewed against the source-of-truth hierarchy. If the correction is right, the fix is made and shipped.
For substantive corrections — anything that changes the meaning of a section or the answer to the page's primary question — a visible "Corrected" note is added to the page, briefly stating what changed.
For trivial corrections (typos, broken links, minor phrasing, updating a screenshot to match a current UI), the change is made in place without a visible note. The git history of the site is public for anyone wanting the full audit trail.

We don't silently rewrite history. If a page used to say something materially wrong, the correction is acknowledged on the page rather than airbrushed out. That standard does not apply to ordinary editorial improvement (a clearer paragraph, a better example) — those are part of normal maintenance.

Send corrections to hello@viewmygpx.com with the URL and what we got wrong. Specifics in a correction request save time: which sentence, which claim, which source contradicts it. We are a small group, not a corrections team; we don't promise a specific turnaround, but factual corrections are prioritized over feature work.

What we won't change on request

Subjective interpretations we stand by. If a platform disagrees with an editorial judgment we made about its behavior — for instance, that the upload flow is confusing compared to a competitor's — and the judgment is supported by our testing, we won't soften it on request. Subjective claims that turn out to be unsupported by testing get rewritten; subjective claims that are supported stay.
Critical coverage. When a platform's documentation is wrong, ambiguous, or out of date, we say so. Our writing about platforms is independent of our relationship with them.
Coverage of free or open alternatives. We cover OpenStreetMap, free tiers, and open-source tools where they're relevant, regardless of whether covering them competes with a commercial platform we also write about.

What we will change: factual errors, broken links, outdated screenshots, claims unsupported by primary sources, and writing that fails the voice rules. The line between "factual" and "subjective" is sometimes a judgment call; when in doubt, we go back to the source-of-truth hierarchy.

Editorial independence

viewmygpx's editorial decisions are not subject to outside approval. The site is run by the people who write it; nobody outside the editorial group can compel a page to be published, unpublished, or rewritten. The only constraints we accept are legal ones (a valid takedown notice for content that genuinely infringes; a court order in a jurisdiction that has authority over us).

We don't accept payment, equity, gifts, or comp accounts in exchange for coverage. Comp accounts that platforms offer to media in general — when a platform asks "would you like a free Premium account so you can test the import flow accurately?" — are accepted only when the comp serves verification work that a paid account would also serve, and the receipt of the comp does not affect editorial judgment.

Privacy and editorial

Email correspondence to hello@viewmygpx.com may be quoted on the site (anonymously, paraphrased, or as direct quotes with consent) when the correspondence is editorially useful — for instance, a reader-flagged correction, a commonly-asked question, a real-world bug report. Identifying details are removed; we don't name correspondents without permission.

If you write to us and would prefer no part of your message be used in any way other than to answer it, say so in the message and we will respect that. The default is to use the substance of the correspondence (not the identity) to make the site better.

Questions

Questions about a specific editorial decision, the sourcing on a specific page, or any of the standards above: hello@viewmygpx.com with the URL and the question. We are happy to show our work.