GeoJSON vs Shapefile vs GeoPackage vs KML

GeoJSON, Shapefile, GeoPackage, and KML can all carry geographic vector data, but they were designed around different assumptions.

GeoJSON is usually the most natural choice for lightweight web and developer workflows. Shapefile remains useful when compatibility with older or widely distributed GIS workflows matters. GeoPackage is generally the strongest of the four for carrying richer GIS data in a single portable file. KML is most appropriate when geographic visualisation and exchange with KML-compatible viewers are central to the task.

The best format therefore depends less on which one is “best” in the abstract than on what needs to survive the exchange: one simple layer, several layers, rich attributes, styling, projection information, human-readable text, database-like structure, or straightforward web consumption.

The difference at a glance

Column 1: Basic structure; GeoJSON: JSON text; Shapefile: Set of related files; GeoPackage: SQLite database in one file; KML: XML text
Column 1: Typical extension; GeoJSON: .geojson / .json; Shapefile: .shp plus companion files; GeoPackage: .gpkg; KML: .kml / .kmz
Column 1: Multiple vector layers in one file; GeoJSON: Not as a conventional GeoJSON dataset; Shapefile: No; GeoPackage: Yes; KML: Yes, through document/folder structures
Column 1: Raster/tile storage; GeoJSON: No; Shapefile: No; GeoPackage: Yes; KML: Can reference/overlay imagery, but not as a general GIS raster database
Column 1: Attribute model; GeoJSON: JSON properties; Shapefile: dBASE table; GeoPackage: SQLite tables; KML: Extended data / KML elements
Column 1: CRS flexibility; GeoJSON: WGS 84 longitude/latitude convention; Shapefile: CRS commonly supplied separately in .prj; GeoPackage: Supports defined CRSs; KML: Geographic coordinates used by KML
Column 1: Human-readable; GeoJSON: Yes; Shapefile: No, as a whole; GeoPackage: No; KML: Yes
Column 1: Particularly natural for web development; GeoJSON: Yes; Shapefile: Rarely; GeoPackage: Sometimes, but not its main strength; KML: Mainly for KML-aware viewers
Column 1: Particularly natural for multi-layer GIS exchange; GeoJSON: Limited; Shapefile: No; GeoPackage: Yes; KML: Not as a general analytical container
Column 1: Strong visualisation semantics; GeoJSON: Limited; Shapefile: Limited; GeoPackage: Limited/core data focused; KML: Yes
Column 1: Main strength; GeoJSON: Simplicity and web interoperability; Shapefile: Legacy compatibility and ubiquity; GeoPackage: Portable, structured GIS container; KML: Geographic presentation and annotation

Those differences reflect the formats' origins. GeoJSON is an IETF-standard JSON interchange format for geographic features. GeoPackage is an OGC standard built on SQLite and designed for direct use as well as exchange. KML is an OGC standard specifically focused on geographic visualisation. Shapefile is an older Esri format whose geometry and attributes are distributed across several cooperating files.

GeoJSON: simple geographic data in JSON

GeoJSON represents geographic features using JSON, the same general data syntax widely used by web applications and APIs.

A minimal feature can combine geometry and ordinary properties:

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

That simplicity is one of GeoJSON's greatest strengths. A developer can inspect it in a text editor, parse it using standard JSON tooling, transmit it through an API, or use it directly with many web-mapping libraries.

RFC 7946 defines GeoJSON specifically as a geographic data interchange format based on JSON. It supports geometries, Features and FeatureCollections and uses WGS 84 geographic coordinates in decimal degrees.

That last point is important: modern GeoJSON is deliberately less flexible about coordinate reference systems than many traditional GIS formats. If you need a file whose coordinates remain in an arbitrary national or projected CRS, GeoJSON is not normally the format to reach for without transforming the data first.

For web interchange, however, that consistency can be an advantage. A receiving application has fewer CRS possibilities to negotiate.

What Is GeoJSON? goes further into Features, geometries, properties, FeatureCollections, and the coordinate conventions of the format.

Shapefile: extremely compatible, but structurally old

A Shapefile is not really a single file despite its name.

At minimum, the format separates geometry, indexing, and attributes into cooperating components. The .shp file stores geometry, .shx stores the geometry index, and .dbf stores attributes. CRS information is commonly carried in an additional .prj file.

This design dates from a very different period of GIS software, and many of its limitations are now conspicuous.

For example, shapefile attributes inherit restrictions from the dBASE format. Current ArcGIS documentation notes limitations including field names of at most ten characters, weak handling of nulls and Unicode, and limited date/time representation. GDAL documents the same ten-character field-name constraint and a restricted set of attribute types.

Yet Shapefile remains remarkably persistent for a good reason: compatibility.

It has been implemented by GIS software for decades. When sending a simple vector layer to an unknown GIS environment, a shapefile still has a good chance of being readable.

That makes it a format worth understanding rather than merely dismissing as obsolete.

The trade-off is that its interoperability comes partly from keeping the data model simple and constrained. When converting richer data into a shapefile, you should check what information may be truncated, renamed, substituted or discarded.

If the collection of companion files itself is the confusing part, Why Is a Shapefile Made of Multiple Files? explains what each component contributes.

GeoPackage: a portable database rather than a loose interchange document

A GeoPackage is conceptually different from both GeoJSON and Shapefile.

It is a SQLite database file organised according to an OGC standard. A single .gpkg can contain multiple vector feature tables, non-spatial attributes, coordinate-system definitions, and tile matrix sets for imagery or raster maps.

That gives it several practical advantages.

Instead of receiving:

roads.shp
roads.shx
roads.dbf
roads.prj

schools.shp
schools.shx
schools.dbf
schools.prj

you can potentially receive:

project_data.gpkg

containing several logically separate datasets.

Because the container is a SQLite database, GeoPackage also offers a substantially richer data environment than a Shapefile. The OGC standard describes it as portable, self-describing, platform-independent, and suitable both for exchange and direct use without first translating the contents into an intermediate format.

This makes GeoPackage particularly attractive when the unit you want to exchange is closer to a small geographic database than a single simple layer.

It is not necessarily the best answer for sending five points to a JavaScript application. For that, GeoJSON may be much easier.

But if you need to preserve multiple layers and richer GIS structure inside one portable file, GeoPackage is often the more capable choice.

The more specific trade-off with the older format belongs in GeoPackage vs Shapefile.

KML: geographic data organised around presentation

KML is different again because its design is strongly concerned with geographic visualisation.

The OGC describes KML as an XML language focused on geographic visualisation, including annotation of maps and images, and summarises its purpose as encoding what to show in an Earth browser and how to show it.

That heritage is visible in the format.

KML can carry geometry and associated information, but it also has concepts for presentation and navigation that are not central to Shapefile or GeoJSON. Styles, icons, placemarks, descriptive content, camera/view information, folders, overlays and other presentation-oriented elements can all be part of a KML document.

This makes KML useful when the thing being exchanged is not merely a vector dataset but a prepared geographic presentation intended for a compatible viewer.

For example, if someone wants to distribute a set of locations with specific icons and descriptions for exploration in Google Earth or another KML-aware application, KML can be a very natural format.

If the same data needs to become the authoritative input to a larger analytical workflow, another representation may be more convenient.

The distinction is subtle but important:

GeoJSON commonly behaves like geographic data for applications.

KML commonly behaves like geographic content for presentation.

There is overlap, but their centres of gravity are different.

Which format should you choose?

A useful answer starts with the destination.

Choose GeoJSON when the destination is a web application or API

GeoJSON is usually the easiest of these formats to work with when:

the dataset is relatively modest in size;
the consumer already works with JSON;
you need simple vector features and attributes;
WGS 84 geographic coordinates are appropriate;
being human-readable and easy to inspect is valuable.

Its simplicity is also its limit.

A large or geometry-heavy GeoJSON document can become inefficient to transfer, parse and render because the format serialises coordinates and properties as text and commonly delivers the feature collection as a relatively monolithic document.

So “web format” should not be interpreted as “best web format at every scale”. The boundary is explored separately in How Large Is Too Large for GeoJSON?.

Choose Shapefile when compatibility is the overriding constraint

A Shapefile can still be reasonable when:

the data consists of simple vector features;
attributes are uncomplicated;
the recipient explicitly requests a shapefile;
compatibility with older GIS software matters;
you are participating in an established workflow built around the format.

What you should not do is select Shapefile merely because it is familiar.

If the source dataset has long field names, meaningful null values, complex attribute types, multiple layers, or other richer characteristics, conversion to Shapefile can involve compromises.

Choose GeoPackage when you want a richer portable GIS container

GeoPackage is particularly compelling when:

several layers should travel together;
you want one portable file rather than a family of sidecar files;
the data should retain its own CRS information;
attributes need a richer database representation;
vector data and tile-based raster content may need to coexist;
the recipient uses GIS software with GeoPackage support;
the file may be queried or edited directly rather than treated only as a transfer envelope.

It is therefore often a strong default for modern desktop-GIS exchange when there is no requirement to use an older format.

Choose KML when geographic presentation is part of the payload

KML makes sense when:

the target environment is Google Earth or another KML-compatible viewer;
placemarks, descriptions, styling or geographic navigation matter;
you are distributing geographic information primarily for visual exploration;
the format's presentation semantics are useful to the recipient.

It is less compelling merely as a generic replacement for a GIS database or analytical vector format.

What about KMZ?

A .kmz file is essentially a packaged form of KML.

Rather than distributing the KML document and supporting resources separately, KMZ uses a ZIP archive so that related content—such as images or icons—can travel together.

That makes KMZ convenient for distributing a self-contained KML presentation, but it does not fundamentally change the data model into something equivalent to GeoPackage.

The distinction between the two KML forms deserves its own short treatment in KML vs KMZ.

One file is not automatically better than several

GeoPackage's single-file design is clearly convenient compared with Shapefile's collection of companion files.

But file count alone is not a useful way to rank formats.

GeoJSON is often a single file because its model is deliberately straightforward. GeoPackage is a single file because SQLite acts as a database container. KML can be a single XML document or packaged into KMZ. A Shapefile distributes different responsibilities across several files.

Those structures affect practical behaviour.

A forgotten .dbf can make a shapefile lose its attributes. A missing .prj can leave its CRS unclear. A damaged GeoPackage may affect several layers because they share one container. A giant GeoJSON file may be easy to copy yet expensive for a browser to parse.

The right question is therefore not:

Which format gives me the fewest files?

but:

Which structure best matches how this dataset needs to be stored, exchanged and used?

Conversion is not necessarily lossless

Another reason format choice matters is that converting a dataset changes more than its filename.

Consider moving a rich dataset from GeoPackage to Shapefile. Long column names may have to be shortened. Null handling may change. Attribute types may need to be simplified. Multiple layers must become separate shapefiles.

Moving arbitrary projected data to standard GeoJSON introduces a different requirement: RFC 7946 uses WGS 84 geographic coordinates, so a conforming GeoJSON workflow may require coordinate transformation rather than merely serialising the original numbers into JSON.

KML introduces its own representation and presentation semantics.

The fact that two formats can both represent points and polygons does not mean that everything surrounding those geometries survives a conversion unchanged.

What Information Can Be Lost When Converting GIS Formats? will treat that problem directly.

Format and workflow should be chosen together

There is a tendency in GIS to treat file formats as passive containers: data exists first, and at the end someone chooses an extension.

In practice, the format can influence the workflow.

GeoJSON fits naturally into APIs, source control, browser tooling and other JSON-oriented systems.

Shapefile fits environments where a simple layer needs to cross a very broad compatibility boundary.

GeoPackage behaves more like a portable spatial database and can carry several pieces of a GIS project together.

KML can preserve parts of the intended geographic presentation and viewer experience.

This is also why openness is not just a matter of picking whatever format happens to be labelled “open”. Geobble's existing Journal essay, Open Geospatial Foundations for a Modern GIS Platform, makes the broader architectural argument that geographic information should cross system boundaries through representations that remain understandable and usable outside one application.

The appropriate format is part of that boundary.

There is no universal winner

If you need a concise recommendation:

For a lightweight web-facing vector dataset, start by considering GeoJSON.

For a modern portable GIS dataset with several layers or richer structure, consider GeoPackage.

For compatibility with an established shapefile-based workflow, Shapefile may still be the pragmatic choice—but understand its limitations.

For geographic visualisation intended for KML-aware viewers, KML or KMZ may be the most natural representation.

Those are starting points, not absolute rules.

A 500 MB GeoJSON file can be a poor web-delivery choice even though GeoJSON is web-friendly. A GeoPackage can be unnecessary overhead for ten points sent through an API. A shapefile can be exactly what a recipient needs despite its ageing data model. A KML document can be excellent for communicating a prepared geographic view and awkward as the core of an analytical pipeline.

The best format is the one whose strengths line up with the next operation—and whose limitations do not quietly discard information you still need.

References

IETF RFC 7946 — The GeoJSON Format. Defines GeoJSON as a JSON-based geographic interchange format and specifies its Geometry, Feature, FeatureCollection, and coordinate conventions.
Esri — ESRI Shapefile Technical Description. Defines the Shapefile format and its cooperating geometry, index, and attribute components.
Esri ArcGIS Pro — Geoprocessing Considerations for Shapefile Output. Documents practical Shapefile limitations including field-name length, null handling, character encoding, and date/time representation.
Open Geospatial Consortium — GeoPackage Encoding Standard 1.4.0. Defines the SQLite-based GeoPackage container for vector features, attributes, tile matrix sets, and extensions.
Open Geospatial Consortium — KML. Describes KML as an XML language focused on geographic visualisation, annotation, and presentation.