GeoJSON Best Practices: Tips for Clean Data

GeoJSON has become the dominant format for exchanging geospatial data on the web, yet many datasets contain avoidable issues that degrade performance, break interoperability, and introduce subtle bugs. Following GeoJSON best practices ensures your files are lean, standards-compliant, and ready for any consumer — from Leaflet to PostGIS. This guide covers the most impactful habits you can adopt today, whether you are authoring GeoJSON by hand, exporting from a GIS, or generating it programmatically.

1. Limit Coordinate Precision

One of the simplest GeoJSON best practices is trimming coordinate precision. Six decimal places give you roughly 0.11 m accuracy at the equator — more than enough for the vast majority of applications. Extra decimals inflate file size without adding meaningful spatial information.

Good vs Bad Coordinate Precision

// ❌ Excessive — 15 decimal places, ~70 extra bytes per coordinate pair
{
  "type": "Point",
  "coordinates": [-73.985707000000004, 40.748440000000002]
}

// ✅ Recommended — 6 decimal places, ~0.11 m accuracy
{
  "type": "Point",
  "coordinates": [-73.985707, 40.748440]
}

When a dataset contains thousands of features, the cumulative savings from reducing precision are significant. A polygon with 500 vertices can shed 10–20 KB simply by rounding to six decimal places. If centimeter-level accuracy is genuinely required (e.g., survey data), use the precision your application needs — but never more.

2. Follow the Right-Hand Rule (RFC 7946)

The RFC 7946 specification mandates that exterior polygon rings follow a counterclockwise winding order and interior rings (holes) follow a clockwise order. This convention is known as the right-hand rule. Violating it does not always cause visible errors, but many tools — including Mapbox GL JS and Turf.js — rely on correct winding order to determine which side of a ring is "inside" a polygon.

• Exterior rings — counterclockwise (right-hand rule)
• Interior rings (holes) — clockwise

If your polygons render as inverted (the entire world is filled except your shape), incorrect winding order is the most likely cause. Tools like GeoDataTools can detect and fix winding order automatically during validation.

3. Handle the Antimeridian Correctly

Features that cross the 180° meridian (antimeridian) require special care. RFC 7946 recommends splitting geometries at the antimeridian into separate parts rather than wrapping coordinates past ±180°. A LineString from Japan to Alaska, for example, should be represented as a MultiLineString with one segment ending at 180° and another starting at -180°.

• Never let longitude values exceed the range [-180, 180].
• Split polygons and lines at the antimeridian boundary.
• Test with a global-extent map view to catch rendering artifacts early.

Ignoring antimeridian handling leads to lines that stretch across the entire map — a common bug in datasets that cover the Pacific region.

4. Use Consistent Property Naming

Properties are free-form JSON, which means there is no schema enforcement by default. Adopting a consistent naming convention avoids confusion when multiple contributors edit the same dataset or when properties are consumed by downstream APIs.

Property Naming Example

// ❌ Inconsistent naming and types
{
  "properties": {
    "Name": "Central Park",
    "AREA_KM": "3.41",
    "pop-count": null,
    "Is_Public": "yes"
  }
}

// ✅ camelCase, consistent types, no nulls where avoidable
{
  "properties": {
    "name": "Central Park",
    "areaKm": 3.41,
    "populationCount": 0,
    "isPublic": true
  }
}

Guidelines worth following:

• Use camelCase for property keys.
• Keep value types consistent across all features — if areaKm is a number in one feature, it should be a number in every feature.
• Avoid null when a sensible default (0, false, empty string) exists.
• Document the schema in a companion README or data dictionary.

5. Always Use FeatureCollection as the Root

While the GeoJSON specification allows a bare Geometry or a single Feature as a top-level object, wrapping everything in a FeatureCollection is the safest choice. Most libraries and services expect a FeatureCollection, and using one from the start avoids the need to refactor later.

Correct FeatureCollection Structure

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Polygon",
        "coordinates": [[
          [-73.981, 40.768],
          [-73.958, 40.800],
          [-73.949, 40.797],
          [-73.973, 40.764],
          [-73.981, 40.768]
        ]]
      },
      "properties": {
        "name": "Central Park",
        "areaKm": 3.41,
        "isPublic": true
      }
    }
  ]
}

Even if your file contains a single feature, wrapping it in a FeatureCollection keeps the structure predictable and compatible with tools like GeoJSON-to-KML converters and KML-to-GeoJSON converters that expect this root type.

6. Optimize File Size

Large GeoJSON files slow down network transfers and client-side rendering. Beyond trimming coordinate precision, consider these strategies:

• Remove unused properties. If a feature carries 30 properties but the consumer only needs 3, strip the rest before export.
• Simplify geometries. Algorithms like Douglas-Peucker reduce vertex counts while preserving shape. Use an appropriate tolerance for your zoom level.
• Minify the JSON. Remove whitespace and indentation for production files. A 5 MB pretty-printed file can often shrink to 3 MB minified.
• Serve with gzip or Brotli compression. GeoJSON compresses well — expect 60–80 % size reduction over the wire.
• Consider alternatives for very large datasets. Formats like GeoPackage, FlatGeobuf, or vector tiles handle millions of features more efficiently than a single GeoJSON file.

7. Validate Before Publishing

Validation catches structural errors, invalid coordinates, and specification violations before they reach consumers. A robust validation workflow includes:

• Schema validation — Confirm the JSON structure matches the GeoJSON specification.
• Geometry validation — Check for self-intersecting polygons, duplicate vertices, and unclosed rings.
• Coordinate range checks — Longitude must be in [-180, 180] and latitude in [-90, 90].
• Winding order verification — Ensure rings follow the right-hand rule.

You can validate GeoJSON interactively using the GeoDataTools validator, which highlights issues on a map and provides actionable error messages. For automated pipelines, libraries like geojsonhint (JavaScript) and geojson-pydantic (Python) integrate validation into CI/CD workflows. Refer to our GeoJSON validation and debugging guide for a deeper walkthrough.

8. Common Mistakes and How to Avoid Them

The table below summarizes frequent GeoJSON pitfalls alongside the recommended best practice for each.

Common Mistake	Best Practice
Coordinates with 15+ decimal places	Round to 6 decimal places (~0.11 m accuracy)
Latitude before longitude ([lat, lng])	Always use [longitude, latitude] per RFC 7946
Clockwise exterior rings	Use counterclockwise exterior rings (right-hand rule)
Bare Geometry as root object	Wrap in a FeatureCollection
Inconsistent property keys (mixed case, dashes)	Use camelCase consistently across all features
Including a CRS property	Omit CRS — RFC 7946 mandates WGS 84 (EPSG:4326)
Longitude values beyond ±180°	Clamp to [-180, 180]; split at antimeridian
Shipping pretty-printed files to production	Minify and serve with gzip or Brotli compression

If you are unsure whether your file contains any of these issues, load it into GeoDataTools to get an instant health check. For a thorough explanation of GeoJSON fundamentals, see our What is GeoJSON? guide.

FAQ

How many decimal places should GeoJSON coordinates have?

Six decimal places are sufficient for most applications, providing approximately 0.11 meter accuracy at the equator. Additional decimals increase file size without meaningful spatial benefit. Use fewer decimals (4–5) for city- or country-level datasets where meter precision is unnecessary, and reserve higher precision only for survey-grade or engineering use cases.

What is the right-hand rule in GeoJSON?

The right-hand rule, defined in RFC 7946, specifies that the exterior ring of a GeoJSON polygon must be ordered counterclockwise when viewed on a standard map. Interior rings (holes) must be ordered clockwise. This convention tells parsers which side of a ring boundary is the interior of the polygon.

How do I validate a GeoJSON file?

The fastest approach is to use a browser-based tool like the GeoDataTools validator, which checks structure, coordinate ranges, winding order, and geometry validity in one step. For programmatic validation, use libraries such as geojsonhint for JavaScript or geojson-pydantic for Python. Integrating validation into your build pipeline prevents malformed data from reaching production.