GeoJSON Specification (RFC 7946)
A developer-friendly guide to the GeoJSON specification RFC 7946 with examples and explanations.
The GeoJSON format is formally defined in RFC 7946, published by the Internet Engineering Task Force (IETF) in August 2016. It replaced the original 2008 specification and introduced stricter rules around coordinate reference systems, winding order, and bounding boxes.
This guide breaks down the specification into practical, developer-friendly sections.
The Three GeoJSON Object Types
Every valid GeoJSON document must be one of these three types:
1. Geometry — A spatial shape defined by coordinates.
GeoJSON{
"type": "Point",
"coordinates": [-122.4194, 37.7749]
}2. Feature — A geometry paired with a properties object.
GeoJSON{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [-122.4194, 37.7749]
},
"properties": {
"name": "San Francisco"
}
}3. FeatureCollection — An array of Feature objects.
GeoJSON{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"geometry": { "type": "Point", "coordinates": [-122.4194, 37.7749] },
"properties": { "name": "San Francisco" }
}
]
}Geometry Types in Detail
Point — A single position as [longitude, latitude] or [longitude, latitude, altitude].
GeoJSON{ "type": "Point", "coordinates": [100.0, 0.0] }MultiPoint — An array of positions.
GeoJSON{ "type": "MultiPoint", "coordinates": [[100.0, 0.0], [101.0, 1.0]] }LineString — Two or more positions forming a connected line.
GeoJSON{ "type": "LineString", "coordinates": [[100.0, 0.0], [101.0, 1.0]] }MultiLineString — An array of LineString coordinate arrays.
GeoJSON{
"type": "MultiLineString",
"coordinates": [
[[100.0, 0.0], [101.0, 1.0]],
[[102.0, 2.0], [103.0, 3.0]]
]
}Polygon — An array of linear rings. The first ring is the exterior boundary; any subsequent rings are holes.
GeoJSON{
"type": "Polygon",
"coordinates": [
[[100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0]]
]
}A polygon with a hole:
GeoJSON{
"type": "Polygon",
"coordinates": [
[[100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0]],
[[100.2, 0.2], [100.8, 0.2], [100.8, 0.8], [100.2, 0.8], [100.2, 0.2]]
]
}MultiPolygon — An array of Polygon coordinate arrays.
GeometryCollection — A heterogeneous collection of geometry objects.
GeoJSON{
"type": "GeometryCollection",
"geometries": [
{ "type": "Point", "coordinates": [100.0, 0.0] },
{ "type": "LineString", "coordinates": [[101.0, 0.0], [102.0, 1.0]] }
]
}Coordinate Order and CRS
RFC 7946 mandates:
- Coordinate order is [longitude, latitude, altitude] — longitude first, always.
- WGS 84 (EPSG:4326) is the only allowed CRS — the older 2008 spec allowed a
crsmember, but RFC 7946 removed it. All GeoJSON coordinates must be in WGS 84. - Altitude is optional and expressed in meters above the WGS 84 reference ellipsoid.
- Longitude ranges from -180 to 180, latitude from -90 to 90.
Winding Order (Right-Hand Rule)
RFC 7946 Section 3.1.6 specifies polygon winding order:
- Exterior rings must be counterclockwise (CCW)
- Holes must be clockwise (CW)
Many tools are lenient about this, but for strict RFC 7946 compliance, winding order matters. Use our GeoJSON Rewind Tool to fix winding order automatically.
Bounding Box (bbox)
Any GeoJSON object may include a bbox member — an array defining the spatial extent:
- 2D bbox:
[west, south, east, north](4 values) - 3D bbox:
[west, south, min-altitude, east, north, max-altitude](6 values)
GeoJSON{
"type": "Feature",
"bbox": [-180.0, -90.0, 180.0, 90.0],
"geometry": {
"type": "Polygon",
"coordinates": [[ ... ]]
},
"properties": {}
}Use our Bounding Box Calculator to compute the bbox for any GeoJSON.
The properties Member
A Feature's properties member can be any JSON object or null. The spec imposes no structure — you decide what metadata to include:
GeoJSON"properties": {
"name": "Central Park",
"area_km2": 3.41,
"amenities": ["playground", "zoo", "reservoir"],
"open": true,
"address": null
}Foreign Members
GeoJSON objects may contain members not described in the specification (called "foreign members"). Common examples include id, title, or style. While allowed, parsers are not required to understand them:
GeoJSON{
"type": "Feature",
"id": "park-001",
"geometry": { "type": "Point", "coordinates": [-73.97, 40.77] },
"properties": { "name": "Central Park" }
}Note: id on a Feature is explicitly mentioned in the spec as allowed (Section 6.1) and should be either a string or number.
Antimeridian Cutting
Features that cross the antimeridian (180°/-180° longitude) should be split into two parts rather than wrapping. This ensures compatibility with mapping libraries that expect coordinates within the -180 to 180 range.
Common Specification Mistakes
| Mistake | Correct Approach |
|---|---|
Using [latitude, longitude] | Always use [longitude, latitude] |
Including a crs member | Remove it — WGS 84 is assumed |
| Open polygon rings | Close them — first and last position must match |
| Wrong winding order | Exterior CCW, holes CW |
| Coordinates outside valid range | Longitude: -180 to 180, Latitude: -90 to 90 |
Further Reading
- RFC 7946 Full Text — the official specification
- GeoJSON Validator — validate your GeoJSON against the spec
- What is GeoJSON? — beginner-friendly introduction