What Is GeoJSON?

GeoJSON is a format for representing geographic data using JSON. It can describe points, lines, polygons and multipart geometries, combine those geometries with attributes as Features, and group multiple Features into a FeatureCollection.

A simple GeoJSON dataset might therefore contain a point representing a school, together with properties such as its name and type:

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [11.52, 3.87]
  },
  "properties": {
    "name": "Illustrative School",
    "type": "Primary"
  }
}

Because GeoJSON uses ordinary JSON structures, it fits naturally into web applications, APIs and programming workflows. But it is still a geographic format with specific rules: coordinate order matters, modern standard GeoJSON uses WGS 84 longitude and latitude, and large or geometrically complex files can become inefficient despite the format's apparent simplicity.

RFC 7946, the current IETF standard, describes GeoJSON as a geographic data interchange format built on JSON and defines Geometry, Feature and FeatureCollection as its central object types.

GeoJSON adds geography to JSON

JSON by itself has no concept of geography.

This is perfectly valid JSON:

{
  "name": "Illustrative School",
  "longitude": 11.52,
  "latitude": 3.87
}

A human—or an application written specifically for that schema—can recognise that the two numbers represent a location. But there is nothing in JSON itself that says they form a geographic point.

GeoJSON gives geographic structures a standard representation.

The same information can instead be written as:

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [11.52, 3.87]
  },
  "properties": {
    "name": "Illustrative School"
  }
}

Now software that understands GeoJSON can recognise the object as a geographic Feature, identify its Point geometry and access its non-spatial attributes through properties.

That shared structure is the format's central advantage. Different systems do not need to invent their own JSON schema every time they exchange simple geographic features.

Geometry, Feature, and FeatureCollection

These three concepts explain most ordinary GeoJSON files.

Geometry describes shape and location

A GeoJSON Geometry represents the spatial part of something.

RFC 7946 defines seven geometry types:

• Point

• MultiPoint

• LineString

• MultiLineString

• Polygon

• MultiPolygon

• GeometryCollection

The first six describe familiar vector geometry types. GeometryCollection allows different geometries to be combined in one geometry object.

A Point is straightforward:

{
  "type": "Point",
  "coordinates": [11.52, 3.87]
}

A LineString contains several positions:

{
  "type": "LineString",
  "coordinates": [
    [11.50, 3.85],
    [11.52, 3.87],
    [11.55, 3.89]
  ]
}

A Polygon adds another level of nesting because its coordinates describe one or more rings:

{
  "type": "Polygon",
  "coordinates": [
    [
      [11.50, 3.85],
      [11.55, 3.85],
      [11.55, 3.90],
      [11.50, 3.90],
      [11.50, 3.85]
    ]
  ]
}

The nesting can initially look cryptic, but it follows the geometry's structure: a LineString contains positions, while a Polygon contains rings made from positions.

A more detailed distinction between the spatial object and the record surrounding it belongs in Geometry vs Feature in GeoJSON.

A Feature combines geometry with information about the thing

Most real datasets need more than shape.

A school point may have a name. A road may have a classification. A district polygon may have a population value.

GeoJSON represents that combination with a Feature:

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [11.52, 3.87]
  },
  "properties": {
    "name": "Illustrative School",
    "category": "Primary"
  }
}

The geometry member says where or what shape the Feature has.

The properties member carries its associated non-spatial information.

RFC 7946 permits properties to contain any JSON object or to be null. A Feature can also have an optional id, and its geometry may itself be null when the feature exists conceptually but has no geometry represented.

That distinction is useful because a Feature is not synonymous with a geometry. The geometry is one component of the record.

A FeatureCollection groups Features

A dataset commonly contains more than one Feature.

GeoJSON uses a FeatureCollection for that:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [11.52, 3.87]
      },
      "properties": {
        "name": "School A"
      }
    },
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [11.56, 3.91]
      },
      "properties": {
        "name": "School B"
      }
    }
  ]
}

The features member is simply an array of Feature objects.

This is the structure people often have in mind when they refer to “a GeoJSON file”, although GeoJSON does not require the top-level object to be a FeatureCollection. A standalone Geometry or Feature can also be valid GeoJSON.

Coordinates come longitude first

One of the easiest GeoJSON mistakes is reversing latitude and longitude.

A position in GeoJSON follows this order:

[longitude, latitude]

not:

[latitude, longitude]

So an illustrative point at 11.52° east and 3.87° north is written as:

"coordinates": [11.52, 3.87]

This follows the x-y convention in which longitude behaves like the horizontal coordinate and latitude like the vertical one.

RFC 7946 is explicit that the first two elements of a position are longitude and latitude, or easting and northing in the coordinate reference system being discussed by the specification. For standard GeoJSON, that means longitude followed by latitude in decimal degrees.

This is particularly worth remembering because people naturally say “latitude and longitude”, while the data structure writes them in the opposite order.

Latitude vs Longitude: Which Comes First? explains why both conventions exist and why the format or interface should determine the order you use.

Modern GeoJSON does not let each file choose an arbitrary CRS

Older GeoJSON conventions allowed a crs member through which a document could declare another coordinate reference system.

RFC 7946 removed that mechanism.

Standard GeoJSON coordinates use a geographic coordinate reference system based on WGS 84, with longitude and latitude expressed in decimal degrees. The standard describes this convention as equivalent to OGC CRS84.

That means a dataset stored in a projected CRS should not simply have its existing coordinates placed into an RFC 7946 GeoJSON document.

Suppose a projected dataset contains:

610000, 445000

Those values might be perfectly legitimate eastings and northings in their source CRS. They are not valid GeoJSON longitude and latitude values merely because they have been placed inside a "coordinates" array.

A standards-compliant conversion generally needs to transform the positions into the WGS 84 longitude-latitude convention expected by GeoJSON. GDAL's RFC 7946 output mode does exactly this, reprojecting source data when necessary.

This is another case where changing the coordinate representation requires an actual transformation rather than simply changing the CRS label.

GeoJSON can contain a third coordinate

Positions are most commonly two-dimensional:

[longitude, latitude]

GeoJSON also allows an optional third element representing height in metres above or below the WGS 84 reference ellipsoid:

[longitude, latitude, height]

RFC 7946 advises against extending position arrays beyond three elements because the semantics of additional dimensions are not standardised by the format.

This is important when converting richer GIS data. A source format may distinguish x, y, z and measured values, but standard GeoJSON does not provide a general-purpose model for every possible coordinate dimension.

Again, the fact that two formats can store a geometry does not guarantee that conversion between them preserves every aspect of that geometry.

What are properties allowed to contain?

One advantage of GeoJSON's JSON foundation is that Feature properties are not restricted to a flat table of short text and numeric fields.

A Feature might contain:

{
  "properties": {
    "name": "Illustrative School",
    "students": 420,
    "public": true,
    "tags": ["primary", "urban"],
    "contact": {
      "phone": null,
      "website": "example"
    }
  }
}

JSON can express strings, numbers, booleans, nulls, arrays and nested objects.

That makes the potential property model much more flexible than a format such as Shapefile, whose DBF attribute structure has comparatively strict field types and naming limitations.

Whether every GIS application preserves deeply nested GeoJSON properties equally well is a separate interoperability question. A format can technically represent something that a particular application's internal feature model does not handle naturally.

So when exchanging data between GIS packages rather than JSON-oriented applications, simpler property structures may still travel more reliably.

What is a bounding box in GeoJSON?

GeoJSON objects can optionally contain a bbox member describing their spatial extent.

For a two-dimensional object, the usual form is:

"bbox": [west, south, east, north]

For example:

{
  "type": "FeatureCollection",
  "bbox": [11.4, 3.7, 11.8, 4.1],
  "features": []
}

The bounding box is metadata about the coordinate range. It does not replace the actual geometries.

RFC 7946 defines bounding boxes with the axes of the southwestern position first, followed by the axes of the northeastern position, with special handling needed around the antimeridian.

A bounding box can help an application understand roughly where a dataset lies without inspecting every coordinate, although not every GeoJSON document includes one.

What GeoJSON does not standardise

GeoJSON represents geography and properties, but it is not a complete map-document format.

For example, RFC 7946 does not define a general standard for:

• fill colours;

• line colours;

• symbol icons;

• labels;

• legends;

• popup design;

• layer order;

• map projection for display;

• basemap selection;

• zoom-dependent styling.

Applications can create their own conventions or additional members, but those extensions should not be assumed to have portable meaning everywhere.

This distinction matters because data is not the same thing as a Map.

A GeoJSON polygon can tell an application where a district boundary lies and provide attributes associated with it. It does not, by itself, establish that the district should be coloured blue, labelled at zoom level 8, placed above a road layer and given a particular popup.

That difference is one reason geographic data and cartographic presentation often need separate representations.

Why GeoJSON works so well on the web

GeoJSON fits naturally into web development because its underlying syntax is JSON.

That brings several practical advantages:

• browsers and programming languages already have mature JSON tooling;

• APIs can send GeoJSON using familiar HTTP and JSON patterns;

• developers can inspect files directly;

• geometries and properties coexist in one structured document;

• many web-mapping libraries understand the format directly.

Its official media type is application/geo+json, reinforcing its role as a standard interchange representation rather than a software-specific project file.

For relatively small datasets, that combination is extremely convenient.

It is part of why GeoJSON remains such a common boundary between spatial systems and ordinary application development.

But text-based simplicity has a cost

A GeoJSON coordinate such as:

[11.5234567, 3.8765432]

is stored as text characters inside a JSON document.

Repeat that for hundreds of thousands of vertices, add property names to every feature, and the file can grow quickly. The application may also need to download and parse a substantial portion of that document before it can work with the features.

Complex geometries can be particularly expensive because file size is not determined by feature count alone. One polygon with several hundred thousand vertices can be more demanding than thousands of simple points.

That does not make GeoJSON inefficient in every situation. It means its simplicity is best understood in context.

For a few hundred features transferred through an API, it can be excellent.

For a country-scale dataset containing extremely detailed boundaries or millions of features, another delivery model may be substantially more appropriate.

How Large Is Too Large for GeoJSON? owns that practical performance question, while GeoJSON vs Vector Tiles looks at a different way of serving geographic information to web maps.

GeoJSON is not a spatial database

A .geojson file can certainly hold a useful dataset.

But it does not provide the capabilities expected from a database system: indexes, relational constraints, transactional updates, efficient query planning, multiple related spatial tables, or database-level concurrency.

Compare that with a GeoPackage, which is built on SQLite, or PostGIS, which extends PostgreSQL with spatial capabilities.

This is another reason format decisions should follow the workflow.

GeoJSON may be an excellent representation for exchanging the result of a query without being the best place to maintain the authoritative dataset from which that query was produced.

Likewise, exporting a database table as GeoJSON does not transform the JSON file into a replacement for the database.

The broader choices among common interchange formats are compared in GeoJSON vs Shapefile vs GeoPackage vs KML.

.json or .geojson?

You may encounter both.

GeoJSON is syntactically JSON, so .json is not inherently nonsensical. But .geojson communicates much more clearly that the contents follow the geographic structure rather than representing arbitrary JSON.

When the choice is yours, .geojson is generally the more informative extension for a GeoJSON file.

What ultimately determines whether the content is GeoJSON, however, is its structure—not merely the filename.

Renaming:

data.json

to:

data.geojson

does not convert an arbitrary JSON document into GeoJSON.

The document still needs to follow the format.

When should you use GeoJSON?

GeoJSON is a strong choice when:

• you need to exchange vector features with a web application;

• an API should return standard geographic JSON;

• the dataset is small or moderate enough for JSON transfer and parsing to remain practical;

• human-readable data is useful;

• longitude and latitude in the standard WGS 84 convention are appropriate;

• the receiving tools already support GeoJSON well.

It becomes less attractive when:

• the dataset is extremely large or geometrically complex;

• you need to preserve arbitrary projected coordinates as-is;

• several independent layers need to live in one portable container;

• rich database behaviour is required;

• the workflow depends on format-specific styling or presentation;

• you need dimensions or data structures that standard GeoJSON does not model well.

Those limitations do not make GeoJSON a poor format. They define the job it does well.

A simple format with a clear job

GeoJSON is popular partly because its conceptual model is small.

A Geometry describes spatial form.

A Feature gives that geometry properties and identity.

A FeatureCollection groups features into a dataset.

JSON provides the syntax around those concepts, while RFC 7946 establishes the geographic conventions needed for different systems to interpret the coordinates consistently.

That simplicity makes GeoJSON an excellent bridge between GIS and ordinary application development.

But the bridge works because the format imposes constraints. Longitude comes before latitude. Standard GeoJSON uses the WGS 84 geographic coordinate convention. Styling is largely outside the format. Large documents can become expensive to deliver and render.

Understanding those boundaries is more useful than treating GeoJSON as either “the modern GIS format” or “just JSON with coordinates”.

It is neither.

It is a deliberately straightforward way of expressing geographic features in a structure that the wider software ecosystem already knows how to handle.

References

1. IETF RFC 7946 — The GeoJSON Format. The standards-track specification defining GeoJSON geometries, Features, FeatureCollections, coordinates, bounding boxes, and its WGS 84 longitude-latitude convention.

2. GDAL RFC 65 — RFC 7946 GeoJSON. Documents GDAL's implementation of RFC 7946 behaviour, including CRS84 output, reprojection, polygon winding, and antimeridian handling.

3. GDAL — GeoJSON Driver. Documents practical GeoJSON reading and writing behaviour, properties, geometry handling, coordinate precision, and RFC 7946 output support.