GeoJSON formatter and minifier

About this tool

GeoJSON is plain JSON, but a useful formatter needs to understand the geography inside it. This tool rewrites one GeoJSON document in place: a FeatureCollection stays a FeatureCollection, a single Feature stays a Feature, and a bare Point, Polygon, or GeometryCollection stays a bare geometry.

Use it to:

• pretty-print pasted GeoJSON for review, or set Indent units to 0 to minify it;
• round every coordinate to a fixed number of decimal places;
• preserve input key order, use canonical GeoJSON member order, or sort all keys alphabetically;
• add, recompute, or strip bbox members;
• rewind polygon rings to the RFC 7946 right-hand rule;
• keep or drop selected feature properties, including empty values;
• validate common RFC 7946 problems before output: missing type, bad geometry type, out-of-range coordinates, missing Feature members, and unclosed polygon rings.

All processing runs locally in your browser as WebAssembly. The output is still GeoJSON text, so you can copy it straight into a map library, commit it, or pipe it through another tool.

Worked example — pretty-print and validate

Input:

{"type":"Feature","properties":{"name":"Park","note":""},"geometry":{"type":"Point","coordinates":[12.3456789,-9.8765432]}}

With the defaults (indent = 2, validation on, full precision kept), output starts as:

{
  "type": "Feature",
  "properties": {
    "name": "Park",
    "note": ""
  },
  "geometry": {
    "type": "Point",
    "coordinates": [
      12.3456789,
      -9.8765432
    ]
  }
}

Worked example — minify and round coordinates

Set Indent units to 0 and Coordinate decimal places to 5 for URL/API payloads:

{"type":"Point","coordinates":[12.34568,-9.87654]}

Approximate coordinate precision guidance:

Rounding is lossy: keep a full-precision original when the geometry is authoritative.

Worked example — canonical keys and bounding boxes

For a FeatureCollection with a line from [0,1] to [4,-2], choose Key order: Canonical GeoJSON order and Bounding boxes: Add feature bboxes + top-level bbox. The output includes both:

{"type":"FeatureCollection","bbox":[0.0,-2.0,4.0,1.0],"features":[{"type":"Feature","bbox":[0.0,-2.0,4.0,1.0],"geometry":{"type":"LineString","coordinates":[[0,1],[4,-2]]},"properties":{}}]}

Canonical order places GeoJSON members where people expect to find them (type, id, bbox, coordinates / geometries, geometry, properties, features) without sorting your properties object. Pick Alphabetical only when you want every object, including properties, sorted.

Property pruning

keep_properties is a whitelist: if you enter name,id, all other feature properties are removed. drop_properties removes named properties after the keep-list is applied. Drop empty/null feature properties removes values that are null, "", [], or {}.

This only touches Feature.properties; geometry coordinates and top-level metadata are left alone.

Limits and edge cases

• The input must be a single GeoJSON object. For NDJSON, concatenated features, or many files, use geojson-merge first.
• Validation assumes RFC 7946 / WGS 84 coordinate order: [longitude, latitude, altitude?]. Projected coordinates or swapped [lat, lon] pairs may fail range checks; turn validation off only when you know the input is intentionally nonconforming.
• Bounding boxes are simple min/max boxes. A geometry crossing the antimeridian may need a hand-tuned RFC-style bbox rather than the naive global span.
• Low coordinate precision can collapse tiny rings, introduce self-intersections, or move boundaries enough to matter.
• The whole document is parsed in memory. Very large GeoJSON files belong in a desktop GIS or streaming command-line workflow.

FAQ