GeoJSON and the shapefile are the two vector formats most often used to exchange spatial data. Both store points, lines, polygons and their attributes, but they were designed for different environments: the shapefile for desktop GIS in the 1990s, GeoJSON for the web. This article compares their structure, coordinate systems, attribute rules, performance and practical use.

GeoJSON vs Shapefile: What Is the Difference?

The shapefile is a binary format made up of several files that must always travel together, and it can store data in any coordinate system with a full range of attribute types defined in advance. GeoJSON is a single text file in JSON syntax, readable in any editor, always in geographic coordinates, with attributes defined per feature rather than by a fixed table schema.

GeoJSON vs Shapefile

What Is a Shapefile?

A shapefile is a set of files that together describe one feature class. Geometry is stored in the .shp file, an index of record offsets in .shx and attributes in the .dbf table, one row per feature in the same order. The optional .prj file holds the coordinate system definition in WKT, and .cpg records the character encoding of the table.

Because record positions are indexed, software can jump straight to a specific feature without reading the whole file. This makes shapefiles efficient for desktop work, but it also means the format is only valid when all mandatory files are present and share the same base name.

What Is GeoJSON?

GeoJSON describes spatial data with ordinary JSON objects. A FeatureCollection contains features, each with a geometry and a properties object holding the attributes. The format supports Point, LineString, Polygon, their Multi variants and GeometryCollection, and a feature may also have a null geometry.

Since GeoJSON is plain JSON, it works directly with web technologies. A browser can parse it without a library, an API can return it as a response, and it can be stored in document databases or version control, where changes are visible line by line.

Coordinate Systems

This is the difference that causes the most practical problems. RFC 7946 defines a single coordinate reference system for GeoJSON: WGS 84 with longitude and latitude in decimal degrees, in that order. The older 2008 specification allowed a crs member, and some software still writes one, but standards-compliant readers ignore it and interpret the numbers as degrees.

A shapefile carries its coordinate system in the .prj file and can store data in any projection, which is why projected shapefiles must be reprojected to WGS 84 before conversion to GeoJSON. If the .prj file is missing, the software cannot know the projection and usually assumes a default, which places the data in the wrong location.

Attributes and Encoding

The dBASE table behind a shapefile imposes several limits: field names of up to 10 characters, a maximum of 255 fields, text values up to 254 characters, and date fields that store the date but not the time. Null values are not supported, so empty numbers become zero and empty text becomes a blank string, which changes the meaning of the data during analysis.

Encoding is a separate source of trouble. The dBASE standard was built around single-byte code pages, so non-Latin attribute values appear as unreadable characters when the .cpg file is missing or wrong. GeoJSON avoids this entirely by requiring UTF-8, and it places no restriction on field names or value length, so attributes survive conversion without truncation.

File Size and Performance

A shapefile component cannot exceed 2 GB, which corresponds to roughly 70 million points, and shapefiles also occupy noticeably more disk space than a geodatabase for the same data. GeoJSON has no size limit in the specification, but text is verbose: coordinates are stored as decimal strings and every feature repeats all property names, so the same dataset is usually several times larger than a shapefile.

The bigger constraint is how the file is read. There is no index in GeoJSON, so an application normally parses the whole file into memory before drawing anything. A file of a few megabytes is comfortable in a browser, tens of megabytes are slow, and hundreds of megabytes are impractical. For large datasets, vector tiles, FlatGeobuf, GeoParquet or a spatial database are better options than a single GeoJSON file.

Web Maps and APIs

Web mapping libraries such as Leaflet, OpenLayers, MapLibre and the ArcGIS Maps SDK read GeoJSON natively, and OGC API - Features returns it as the default response format. Attributes arrive as JavaScript objects, so they can be used directly in pop-ups, filters and styling rules without conversion.

Shapefiles cannot be displayed in a browser without extra processing. A web application either converts them on the server or unpacks the binary files with a JavaScript library, which is why services that accept shapefile uploads convert them to hosted layers or another internal format immediately.

Converting Between the Formats

Conversion in both directions is supported by GDAL/OGR, QGIS, ArcGIS Pro and most online tools, but it is not lossless. Going from shapefile to GeoJSON requires reprojection to WGS 84 and often reveals truncated field names that were created earlier. Going from GeoJSON to shapefile splits mixed geometry types into separate files, truncates long field names, discards nested properties and converts null values into zeros or empty strings.

Common Mistakes

The most frequent mistake is sending an incomplete shapefile. Without .shx or .dbf the data cannot be opened at all, and without .prj the coordinate system has to be guessed. When a shapefile is shared, all the files should be packed into a single archive.

The second is assuming that GeoJSON can hold projected coordinates. Coordinates in metres written into a GeoJSON file are read as degrees, so the geometry ends up far outside the valid range or collapses near the origin of the map.

The third is using GeoJSON as a working format for large or frequently edited datasets. Every edit rewrites the entire file, and there is no way to query a subset without reading everything, so a database or geopackage is a better choice once the data grows or several people work on it.

FAQs

Is GeoJSON replacing the shapefile?

In web development and open data publishing, largely yes. In desktop GIS, shapefiles are still widely produced because many organizations and software workflows rely on them, although GeoPackage is increasingly recommended as the modern replacement.

Can GeoJSON store data in a projected coordinate system?

Not according to RFC 7946. Some tools still write a crs member or accept projected coordinates by agreement between the parties, but such files are not interoperable and will be misplaced by standard-compliant software.

Why were my field names shortened after export?

Because shapefile attributes are stored in a dBASE table, which allows only 10 characters per field name. Longer names are truncated and duplicates are renumbered, so the original names should be documented separately or the data exported to another format.

What size of GeoJSON file is acceptable for a web map?

As a rough guide, files up to a few megabytes load comfortably. Beyond that, geometry should be simplified, attributes reduced, or the data served as vector tiles or through an API that returns only the features within the current view.

Which format should I use to share data with a colleague?

If the recipient works in a browser or with an API, GeoJSON in WGS 84. If they work in desktop GIS and the data has a single geometry type and simple attributes, a zipped shapefile is still accepted everywhere. For anything more complex, GeoPackage avoids the limitations of both.

Key Takeaways

GeoJSON and the shapefile solve the same task in different eras of GIS. The shapefile stores data compactly and with an index, keeps its own coordinate system and is deeply embedded in desktop workflows, at the cost of multiple files and a restrictive attribute table. GeoJSON is a single readable file that works natively on the web, at the cost of size, a fixed coordinate system and the absence of an index.

In practice, the choice follows the destination of the data. For web maps, APIs and open data portals, GeoJSON is the natural format. For desktop exchange, shapefiles remain a safe default, but when attributes, volume or data structure matter, GeoPackage is the better modern option.