GeoJSON Viewer

Validate, inspect and convert GeoJSON privately

Drop a .geojson file — or paste raw GeoJSON text — and this workbench validates the structure, reports the feature count by geometry type, draws everything on an interactive map and lists every feature for property inspection on click. Points, MultiPoints, lines, MultiLines, polygons, MultiPolygons and GeometryCollections are all supported, exactly per spec. Invalid JSON gets a precise, human error (trailing commas and unquoted keys are named offenders) instead of a silent failure.

The privacy guarantee is architectural: parsing happens in your browser via FileReader and DOMParser, and the file never touches a server — check the network tab to verify. When you need other ecosystems, one-click exports convert to KML or GPX with names and properties preserved as far as each format allows, and GeoJSON re-download normalises what you pasted. Bounding-box zoom frames any dataset instantly. It is the first stop for QA on exports from QGIS, Mapshaper, Felt or any API you trust slightly less than you should.

Worked examples

• A 1,000-point GPX track — parses in milliseconds locally, yields distance/gain/duration stats, and converts to GeoJSON with elevation preserved as the third coordinate.
• KMZ gotcha — a KMZ is a ZIP archive — unzipping reveals the .kml inside, which then loads with placemarks, names and ExtendedData intact.
• 10,000-row CSV — stays fluid with clustering; the skipped-row counter reports invalid coordinates instead of silently dropping them.

KML, GeoJSON, GPX: the three dialects of geographic data

Three formats carry most consumer geographic data, and each reflects its ancestry. KML is XML from the Google Earth era: folders, styling, descriptions and ExtendedData, beloved by saved-place collections. GeoJSON is plain JSON from the web-mapping world: trivial to parse, diff and version, native to every modern map library, properties free-form. GPX is the GPS device format: waypoints, tracks and routes, with per-point elevation and timestamps as first-class citizens. Conversions between them are mostly faithful for geometry and lossy for everything else — polygons degrade to boundary tracks in GPX, styling evaporates into GeoJSON, and a wise workflow always keeps the original file.

Because these files are often personal — tracks, client sites, survey points — the right place to open them is your own browser. Parsing with built-in readers (FileReader, DOMParser, JSON.parse) means nothing is uploaded, ever, and validation errors can be precise: trailing commas, unquoted keys and KMZ-inside-ZIP confusion are all detectable and explainable locally. A trustworthy viewer tells you exactly what it understood: feature counts by geometry type, property tables, bounding boxes.

GPX deserves special respect for its elevation story. Gain and loss are sums of positive and negative differences between consecutive trackpoints, and raw GPS elevation is noisy, so honest tools show the profile and the caveats together. Duration appears only when timestamps exist; when they don't, the right behaviour is to say so rather than invent a clock. Data hygiene, like privacy, is a feature you can feel.

Tips & common mistakes

Keep the original file even after converting: GPX→GeoJSON drops timestamps' context, KML→GeoJSON drops styling, and every pipeline has a lossy edge. Originals are cheap; re-acquisition is not.

Validate before trusting exports from unfamiliar tools — open them in a local viewer and check feature counts, bounding boxes and a few property rows. A wrong-axis or swapped-coordinate export is far easier to catch on a map than in a spreadsheet.

For big CSVs, fix the coordinate columns first and map a sample before mapping everything: auto-detection is good but not magical, and one swapped column renders a beautiful map of the wrong ocean.

A professional workflow for geographic files

Treat every incoming geographic file as untrusted until inspected: open it locally, read the validation report, check feature counts by geometry type, and eyeball the bounding box before doing anything else. A bounding box spanning the planet usually means one corrupt vertex; a box in the wrong hemisphere means swapped axes; an empty box means the parser and the file disagree about what a coordinate is. Thirty seconds of inspection prevents most downstream embarrassments, and doing it in-browser keeps confidential data confidential.

Conversions then become deliberate acts with known losses. To GPX you take points and lines, leaving polygons as boundary tracks and dropping rich properties; to KML you gain presentation and lose nothing you needed computationally; to GeoJSON you keep the data and shed the styling. Name the loss on the way out, keep the original on disk, and your pipeline stays auditable — which is the entire difference between a hobby workflow and a professional one.

How professionals use this

• Inspect before converting: counts, bounding box, and three random property rows, every time.
• Keep originals forever; conversions are lossy at the edges and cheap to re-run.
• For CSV imports, confirm the detected lat/lng columns against a known point before mapping all rows.
• Rename exports with date + source + format; filenames are the metadata you'll actually read later.

Step-by-step masterclass

1. 1. Inspect before trusting — Open locally, read the validation line, check feature counts and the bounding box; a planet-spanning box means one corrupt vertex, a wrong-hemisphere box means swapped axes.
2. 2. Sample properties by eye — Three random rows of properties catch encoding and column-shift bugs no schema check will flag.
3. 3. Choose the conversion by its loss — GPX keeps time/elevation, KML keeps presentation, GeoJSON keeps data; name the loss on the way out and keep the original regardless.
4. 4. Confirm CSV columns against a known point — Auto-detection is good, not magical; verify the detected lat/lng pair on the map before rendering all 40,000 rows.
5. 5. Export with meaningful names — Date + source + format in the filename; filenames are the metadata future-you will actually read.

Format culture follows tooling: Google-era workflows still circulate KML, GPS and sport apps speak GPX, and the analytical web has standardised on GeoJSON — so a privacy-first converter that handles all three locally is effectively a universal adapter for a decade of saved places.

Related questions people ask

Quick glossary

GeoJSON

JSON geographic format; the web-mapping native dialect.

KML

XML format from the Google Earth era, with styling and ExtendedData.

GPX

GPS exchange format: waypoints, tracks, routes, elevation, timestamps.

Bounding box

The minimal rectangle enclosing a dataset; the instant sanity check.

ExtendedData

KML's key/value extension block; preserved into GeoJSON properties here.

trkseg

A GPX track segment; multi-segment tracks map to MultiLineString.

The quiet discipline of geographic data hygiene

Teams that handle geographic files well share habits that have nothing to do with software: originals are sacred, conversions are named acts with stated losses, filenames carry provenance, and every incoming file gets thirty seconds of inspection — counts, bounding box, three random rows — before it touches anything downstream. These habits convert the classic failure modes (a KMZ mistaken for KML, a swapped CSV column rendering the wrong ocean, GPZ elevation spikes blamed on the tool) from disasters into logged non-events. The local-first design reinforces them: because nothing uploads, inspection costs nothing and confidentiality survives by architecture rather than promise. In that sense a browser workbench is not a lesser GIS; it is the hygiene layer every serious pipeline needs at the door, catching the messy world before it reaches the clean interior.

• Adopt a house rule: no file enters analysis without a printed validation line.
• Filename schema 'YYYY-MM-DD_source_format' — provenance you'll actually read later.
• Keep a 'losses' note with every conversion; audits become trivial when losses are named.

Honest limits & when to escalate

The file tools' limits are format-inherent and honestly named. GPX carries time and elevation but not polygons or rich properties; KML carries presentation but ages into XML quirks; GeoJSON carries data but no styling; CSV carries anything and guarantees nothing. Conversions therefore always have a named loss, and the professional move — keep the original, export the derivative — is recommended on every export panel. A second boundary is source quality: a track's elevation is only as calm as the receiver that logged it, and a CSV's coordinates are only as sane as the column that birthed them; the viewers show counts, boxes and skipped-row tallies so those truths surface immediately.

What remains after those limits is a genuinely complete local workbench: validation, inspection, measurement, conversion and export, with zero upload. The escalation path is about scale and authority rather than privacy — national cadastral formats, laser-scan point clouds and billion-row rasters belong to GIS workstations; everything a laptop holds is welcome here, and the honesty labels travel with it.

• Cadastral/legal formats → jurisdictional land-registry exports.
• Point clouds and rasters → desktop GIS with proper spatial indexes.
• Certified tracks (evidence, insurance) → chain-of-custody originals, untouched.
• Enterprise pipelines → scripted parsers with schema validation.

Data & methodology note

Parsing uses browser-native readers (FileReader, DOMParser, JSON.parse); files never leave the device. Format fidelity notes accompany every export button.

Category context: Map Files — View, validate and convert KML, GeoJSON, GPX and CSV — right in the browser. This page is one of the map files tools on MapForge; the related-tools links below and the header's Tools menu connect every sibling instrument.