GeoJSON Frequently Asked Questions

Basics

What is GeoJSON?

GeoJSON is a JSON-based open standard for encoding geographic data, defined in RFC 7946 (August 2016). It supports seven geometry types — Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, and GeometryCollection — as well as Feature and FeatureCollection wrapper objects. A minimal valid GeoJSON file marking the Empire State Building is 92 characters: {"type":"Point","coordinates":[-73.9857,40.7484]}. Use our GeoJSON Validator to confirm any file meets the spec.

What's the correct MIME type for GeoJSON?

The official MIME type registered with IANA is application/geo+json, adopted when RFC 7946 superseded the earlier GeoJSON specification in 2016. Before that, many servers used application/json or the unofficial application/vnd.geo+json. If your server is still sending the old type, update your Content-Type headers — some libraries and tile servers now treat application/geo+json as a signal to apply GeoJSON-specific parsing. For static file hosting, Nginx requires an explicit types block entry; Apache requires anAddType directive.

Is GeoJSON an official standard?

Yes. RFC 7946 is an Internet Standard published by the IETF in August 2016. It replaced the original 2008 GeoJSON specification written by Howard Butler, Martin Daly, Allan Doyle, Sean Gillies, Tim Schaub, and Christopher Schmidt. The key differences between the original spec and RFC 7946 are: RFC 7946 mandates WGS 84 coordinates (dropping support for alternative CRS), requires right-hand winding order for polygon rings, and explicitly limits coordinates to longitude and latitude (dropping altitude-as-required). The IETF does not charge for access — the RFC is freely available.

What replaced the original 2008 GeoJSON specification?

RFC 7946 replaced the community-authored geojson.org specification. The original spec allowed a "crs" member to declare alternate coordinate reference systems — a feature RFC 7946 removed entirely, mandating WGS 84 (EPSG:4326) as the only permitted CRS. It also removed the "bbox" requirement and clarified that the "properties" member of a Feature may be null but must always be present. Any GeoJSON written against the original spec that uses a named or linked CRS will fail strict RFC 7946 validation.

Coordinates

Why does GeoJSON use longitude before latitude?

GeoJSON follows the mathematical convention of (x, y) ordering, where longitude is the x axis and latitude is the y axis — the same order used in WKT, PostGIS, and most GIS software. The confusion arises because Google Maps, Leaflet's L.latLng(), and most human-readable addresses write latitude first. RFC 7946 Section 3.1.1 states explicitly: "A position is an array of numbers. There MUST be two or more elements. The first two elements are longitude and latitude." The Golden Gate Bridge in correct GeoJSON order is [-122.4783, 37.8199] — never [37.8199, -122.4783]. Use our Coordinate Flip Tool to correct swapped coordinates in bulk.

How many decimal places should GeoJSON coordinates use?

6 decimal places gives ~0.11 meter precision at the equator, which exceeds consumer GPS accuracy (typically 3–5 meters). 5 decimal places gives ~1.1 meters — sufficient for most web mapping applications. Each extra decimal place beyond 6 adds file size with no practical accuracy benefit: a FeatureCollection with 10,000 points gains roughly 40 KB per unnecessary decimal digit. Our Coordinate Precision Tool strips excess decimals while preserving specified precision. For city-level visualization, 4 decimal places (~11 meters) is often enough.

What coordinate reference system (CRS) does GeoJSON use?

RFC 7946 mandates WGS 84 (World Geodetic System 1984), identified as EPSG:4326. Longitude ranges from −180 to 180, latitude from −90 to 90. Altitude, when present, is in meters above the WGS 84 ellipsoid — not above sea level. The original 2008 spec allowed a "crs" member to declare alternative systems (like EPSG:27700 for British National Grid), but RFC 7946 explicitly forbids this. If your source data is in another CRS, you must reproject to WGS 84 before producing GeoJSON. Tools like ogr2ogr -t_srs EPSG:4326 or QGIS handle this reprojection.

Can GeoJSON coordinates include altitude (Z values)?

Yes. RFC 7946 allows a third element in the coordinate array for elevation in meters above the WGS 84 ellipsoid: {"type":"Point","coordinates":[-73.9857,40.7484,443.2]} marks the Empire State Building's roof at 443.2 meters. However, RFC 7946 states that altitude "SHOULD be interpreted as height in meters above the WGS 84 ellipsoid" and that parsers "MAY ignore" it entirely. Most 2D web mapping libraries (Leaflet, Mapbox GL) silently discard Z values. For 3D visualization you need CesiumJS, Deck.gl, or Mapbox GL with extrusion layers.

What is the valid coordinate range for GeoJSON?

RFC 7946 requires longitude values in the range −180 to 180 and latitude values in the range −90 to 90, inclusive. Coordinates outside this range are invalid and will fail validation. A common source of out-of-range coordinates is reprojection gone wrong — for example, projected coordinates in EPSG:3857 (Web Mercator) use meter values in the millions, which are meaningless as WGS 84 degrees. If your coordinates look like [-8234567, 4543210], you have unprojected Web Mercator data. Use our GeoJSON Validator to catch these errors immediately.

Structure

What's the difference between a Feature and a Geometry?

A Geometry is the pure spatial object — it has a "type" (e.g., "Point") and "coordinates", nothing else. A Feature wraps a Geometry and adds a "properties" object for non-spatial attributes like name, category, or population. A FeatureCollection holds an array of Features. Most mapping libraries expect a FeatureCollection or Feature at the top level — passing a bare Geometry to Mapbox GL's addSource will throw a type error. Always wrap geometries in Features when storing associated data.

Can a Feature have null geometry?

Yes — RFC 7946 Section 3.2 explicitly permits "geometry": null on a Feature. This is used for features whose location is unknown or not yet determined. A Feature with null geometry is still valid GeoJSON and must still have a "properties" member (which may itself be null). Some libraries handle null geometry gracefully (Turf.js skips them in most operations), while others throw. Always check for null geometry before passing features to spatial analysis functions.

What are foreign members in GeoJSON?

Foreign members are any keys in a GeoJSON object that are not defined in RFC 7946. The spec explicitly allows them: "Members not described in this specification... MUST be ignored by parsers." For example, adding "title": "My Map" to a FeatureCollection is valid. Mapbox GL uses this for its own "_geometry" internals; some APIs add"id" at the Feature level (also explicitly supported by RFC 7946 Section 3.2). Foreign members are not properties — they sit alongside "type" and "geometry", not inside "properties".

What is a bbox and when should I include one?

A "bbox" (bounding box) is an optional array of four numbers — [minLon, minLat, maxLon, maxLat] — that declares the spatial extent of the GeoJSON object. Example for the contiguous United States: [-124.77, 24.52, -66.95, 49.38]. bbox is useful for quick spatial filtering without parsing all coordinates, and many tile servers and APIs use it to index features. RFC 7946 makes bbox optional. For 3D data, bbox can have six elements: [minLon, minLat, minAlt, maxLon, maxLat, maxAlt]. A mismatched bbox (one that doesn't contain all features) will cause map libraries to pan to the wrong location.

Can a FeatureCollection be empty?

Yes. {"type":"FeatureCollection","features":[]} is valid GeoJSON. An empty FeatureCollection is useful as an initial state in applications before data loads, as a response when a spatial query returns no results, or as a placeholder layer in a map style. Turf.js and most GeoJSON libraries handle empty FeatureCollections without errors. The "features" key must be present and must be an array — omitting it entirely is invalid.

Can a Polygon have holes?

Yes. A GeoJSON Polygon's "coordinates" array contains one or more rings. The first ring is the exterior boundary; all subsequent rings are holes (interior rings). Per RFC 7946, the exterior ring must follow the right-hand rule (counter-clockwise), and each hole must follow the left-hand rule (clockwise). A polygon representing a building with a courtyard would have two rings. The hole must lie entirely within the exterior ring — overlapping or external holes produce undefined behavior across renderers. Use our Rewind Tool to fix winding order on rings.

Limits & Performance

Is there a maximum GeoJSON file size?

RFC 7946 imposes no size limit — the constraint is practical. GitHub renders GeoJSON files up to 10 MB in the browser; files over that show a "raw" view only. Mapbox GL JS can handle GeoJSON sources up to ~30–50 MB before frame rates degrade on mid-range hardware. The real limit is browser memory: a 100 MB GeoJSON file may expand to 400–600 MB in a parsed JavaScript object. For datasets over 10 MB, consider using the GeoJSON Simplifier and Coordinate Precision Tool first, or switch to FlatGeobuf or vector tiles for production.

How many features can a browser handle?

With Leaflet, performance degrades noticeably above ~10,000 complex polygon features. Mapbox GL JS, which uses WebGL, handles 100,000+ point features smoothly and around 20,000 complex polygons before frame rates drop. Deck.gl (also WebGL) can render 1,000,000+ points at 60 fps on modern hardware. The bottleneck is usually JSON parsing and initial rendering, not sustained display. A FeatureCollection with 50,000 Points parses in ~200ms in Chrome V8; 50,000 complex Polygons may take 2–5 seconds. Cluster points above 10,000 features and use tiles above 100,000.

When should I use something other than GeoJSON?

Switch formats when: (1) Your file exceeds 10 MB — use FlatGeobuf for random access or GeoParquet for columnar analytics. (2) You have topology that must be preserved — use TopoJSON, which encodes shared boundaries once and can be 80% smaller for administrative boundaries. (3) You need streaming large datasets — FlatGeobuf supports HTTP range requests for spatial indexing. (4) You need binary precision — GeoJSON's text encoding introduces rounding; Well-Known Binary (WKB) is exact. (5) You're serving tiles — Mapbox Vector Tiles (MVT/PBF) are 70–80% smaller than equivalent GeoJSON tiles.

Does GeoJSON support styling (colors, stroke width)?

RFC 7946 defines no styling properties. The de facto standard is the simplestyle-spec from Mapbox, which uses properties like "marker-color", "stroke", "fill", and "fill-opacity" as conventional names inside the "properties" object. GitHub renders GeoJSON on a map and respects these simplestyle properties. Leaflet, Mapbox GL, and OpenLayers do not read simplestyle automatically — you must apply styles in your layer configuration code.

Common Problems

Why do my points appear in the ocean (or the wrong continent)?

Almost certainly a coordinate order swap. GeoJSON uses [longitude, latitude] but you've stored [latitude, longitude]. The Empire State Building at [40.7484, -73.9857] (wrong order) places a marker near the coast of Eritrea in the Indian Ocean. At [-73.9857, 40.7484] (correct), it's in Midtown Manhattan. If all your points are wrong by the same offset and mirror each other across the equator or prime meridian, this is the cause. Fix the entire dataset at once with our Coordinate Flip Tool.

Why is my polygon appearing inside-out?

RFC 7946 mandates the right-hand rule: exterior rings must wind counter-clockwise, holes must wind clockwise, when viewed from above in geographic (lon/lat) space. When this is violated, some renderers fill the "outside" of the polygon — which is the entire map minus the shape. Mapbox GL JS enforces winding order and may render or clip the polygon incorrectly. The original 2008 GeoJSON spec did not specify winding order, so older data may have clockwise exterior rings. Fix winding order in bulk with our Rewind Tool, which applies RFC 7946-compliant orientations to all rings.

Why does my GeoJSON fail validation even though it looks correct?

Common causes: (1) Polygon rings are not closed — the last coordinate must exactly equal the first. (2) A "Feature" is missing a "properties" key (null is allowed, but omission is not). (3) Type strings are wrong-cased — "point" is invalid; it must be "Point". (4) A LineString has fewer than 2 positions. (5) A Polygon exterior ring has fewer than 4 positions (a triangle needs 4: 3 unique + 1 closing). Run our GeoJSON Validator to get line-level error messages rather than guessing.

Can GeoJSON represent features that cross the antimeridian (180°)?

RFC 7946 Section 3.1.9 explicitly addresses antimeridian-crossing geometries: they should be split into two separate geometries rather than using longitude values outside −180 to 180. A LineString from Tokyo to Los Angeles that crosses 180° longitude must be represented as two LineStrings that each end at the antimeridian, not as a single LineString with coordinates like [185, 35]. Many renderers will draw the line across the entire map going the wrong direction if you don't split it. This is a known pain point with no elegant workaround in the current spec.

Tools & Ecosystem

Does GitHub render GeoJSON files?

Yes. GitHub has rendered GeoJSON and TopoJSON files directly in the browser since 2013, using Leaflet and MapBox tiles. Any .geojson or .json file containing valid GeoJSON is displayed as an interactive map rather than raw text. Files must be under 10 MB to render — larger files show a warning and a link to the raw file. GitHub respects simplestyle-spec properties ("marker-color", "stroke", "fill") for styling features in the rendered map. This makes GitHub a convenient free GeoJSON viewer for public repositories.

What JavaScript libraries parse and manipulate GeoJSON?

The core ecosystem: Turf.js — 60+ spatial analysis functions (buffer, union, intersect, centroid) that all accept and return GeoJSON. Mapbox GL JS — WebGL renderer that uses GeoJSON as its primary data format. Leaflet — the L.geoJSON() layer renders any GeoJSON FeatureCollection. D3.js — d3.geoPath() projects and renders GeoJSON in SVG. OpenLayers — ol/format/GeoJSON reads and writes GeoJSON. geojson-vt — slices GeoJSON into vector tiles client-side at over 100,000 features per second.

How do I convert a Shapefile to GeoJSON?

The command-line tool ogr2ogr (part of GDAL) is the standard approach: ogr2ogr -f GeoJSON output.geojson input.shp -t_srs EPSG:4326. The -t_srs EPSG:4326 flag reprojects to WGS 84, which is required for valid RFC 7946 GeoJSON. Online tools like mapshaper.org handle drag-and-drop conversion with a preview. Note that Shapefiles cannot store null geometries (they use an empty/null shape type instead), and field names are limited to 10 characters — these constraints don't exist in GeoJSON.

How do I convert GeoJSON to a Shapefile?

Use ogr2ogr -f "ESRI Shapefile" output_dir input.geojson. Be aware of Shapefile limitations that don't exist in GeoJSON: field names are truncated to 10 characters, a single Shapefile can only contain one geometry type (so a FeatureCollection with mixed types will be split into multiple files), and there is no support for nested JSON in properties — complex property values will be serialized to strings or dropped. GeometryCollections have no direct Shapefile equivalent and ogr2ogr will skip or flatten them.

How do I convert GeoJSON to TopoJSON?

Use the official geo2topo CLI from the topojson npm package: npx geo2topo features=input.geojson > output.topojson. TopoJSON is typically 40–80% smaller than equivalent GeoJSON for administrative boundaries because shared edges are encoded once. The tradeoff is that TopoJSON is harder to hand-edit, has narrower library support, and requires a decode step back to GeoJSON before most spatial analysis. D3.js supports TopoJSON natively via topojson-client. See our GeoJSON vs TopoJSON guide for a detailed comparison.

What is geojson-vt and when should I use it?

geojson-vt is a JavaScript library by Mapbox that slices GeoJSON into vector tile pyramid (Z/X/Y) format entirely in the browser, processing over 100,000 features per second on a modern machine. It powers Mapbox GL JS's geojson source type internally. Use it directly when you need to implement custom tile caching or serve tiles from Node.js without a GIS server. The output tiles conform to the Mapbox Vector Tile specification and can be rendered by any MVT-compatible renderer. It handles FeatureCollections with mixed geometry types and preserves all properties.

Can I query GeoJSON in a database?

PostgreSQL with the PostGIS extension stores, indexes, and queries GeoJSON natively. ST_GeomFromGeoJSON('{`{"type":"Point","coordinates":[-73.9857,40.7484]}`}') converts GeoJSON text to a PostGIS geometry, and ST_AsGeoJSON(geom) converts back. SQLite with SpatiaLite supports similar functions. DuckDB added native GeoJSON support in 2023 via the spatial extension, enabling SQL spatial queries on GeoJSON files without a server. See our PostGIS & GeoJSON guide for full query examples.

How does GeoJSON compare to WKT and WKB?

Well-Known Text (WKT) and Well-Known Binary (WKB) are OGC standards used primarily in databases. WKT for the Empire State Building: POINT (-73.9857 40.7484) — note that WKT also uses (x, y) = (lon, lat) order, consistent with GeoJSON. WKB is the binary encoding of WKT and is exact (no floating-point text rounding), 50–70% smaller, and faster to parse — but not human-readable. GeoJSON is the right choice for web APIs and file exchange. WKB is the right choice for database storage and high-performance pipelines. Most GIS tools convert between all three freely.