GeoJSON vs Shapefile: Which Format Should You Use in 2025?

The short answer

If you're publishing to the web, use GeoJSON. If you're handing data to a government agency or a legacy desktop tool, use Shapefile. If neither constraint applies, use GeoPackage instead — but that's a different article.

The long answer is more interesting, because each format wins on different axes and the trade-offs have shifted over the last few years.

A quick refresher

Shapefile (Esri, 1993) is a bundle of at least three files: .shp (geometry), .shx (index), .dbf (attributes), and usually a .prj (projection). It is the lowest common denominator of GIS interchange — every desktop tool reads it, every public-sector procurement requests it, and every legacy plotter prints from it.

GeoJSON (RFC 7946, 2016; informally since 2008) is a single JSON file. Geometries and attributes live in one feature collection, the coordinate system is fixed to WGS 84, and every web mapping library on Earth reads it natively.

Speed and file size

For the same dataset, Shapefile is typically 3 to 5 times smaller than GeoJSON. The binary .shp packs coordinates as IEEE-754 doubles with a fixed-size record header; GeoJSON spells out every coordinate in ASCII, repeats every attribute key on every feature, and pads with whitespace. A Shapefile of 100,000 US Census tracts might be 80 MB; the same data as GeoJSON is 250–400 MB.

Size translates directly into rendering time. A 200 MB GeoJSON takes 5–15 seconds to parse in a modern browser before the first pixel is drawn. The same data in Shapefile loads into QGIS in under a second because the .shx lets the reader seek directly to features without parsing the whole file.

But Shapefile cannot stream over HTTP, cannot be diffed in Git, and cannot be embedded inline in a JavaScript bundle. For its actual use case (desktop GIS), it wins on speed; for the web, it doesn't compete.

Attribute limits

This is where Shapefile shows its age. The .dbf attribute table is the legacy dBASE IV format, frozen since 1988, and it imposes painful limits:

• 10-character field names. population_density becomes populatn_d or POP_DENS. Plan your column names accordingly, or lose information in every round-trip.
• No Unicode by default. Encoding depends on a .cpg sidecar that many tools don't write. Accented characters arrive as ? or worse.
• No nested data. No arrays, no objects, no JSON. Every value is a flat string, number, or date.
• 2 GB file-size cap on .shp and .dbf, inherited from 32-bit file offsets.

GeoJSON has none of these limits. The properties object is schema-free, supports any JSON-serialisable value, allows nesting, and is UTF-8 throughout. The downside is the verbosity overhead this freedom brings.

Coordinate systems

Shapefile carries CRS information in a .prj sidecar containing WKT2. The CRS can be anything — UTM zones, national grids, Web Mercator. Lose the .prj and your data has no known projection, but it can still be reconstructed if you know the source.

GeoJSON, since RFC 7946, is locked to WGS 84 (EPSG:4326) in decimal degrees. The old crs member from GeoJSON 2008 is deprecated. If you need projected data, you either reproject before exporting to GeoJSON (the standard-conformant path) or you accept that your file is non-conformant and hope your readers don't care.

Mixed geometries

A Shapefile holds exactly one geometry type per file. Points, lines, and polygons must live in separate files. GeoJSON allows mixed FeatureCollections where each feature has its own geometry type. In practice, mixing geometries breaks many tools that expect uniform layers — but for use cases like map annotations (a marker, a route, and a polygon highlight in one file), it's genuinely useful.

When Shapefile still wins

• Government and procurement workflows. Public sector data is overwhelmingly distributed as Shapefile. Cadastre, transportation, environmental data — expect .zip archives full of .shp files.
• Legacy desktop tools. If your client uses MapInfo 12, AutoCAD Map 2008, or ArcGIS 9.3, Shapefile is what they read.
• Large datasets on disk. For multi-gigabyte vector data that lives on a workstation, Shapefile loads faster than GeoJSON.

When GeoJSON wins

• Anything in a browser. Leaflet, Mapbox GL, MapLibre, OpenLayers all consume GeoJSON natively.
• APIs and microservices. REST endpoints returning spatial data almost universally return GeoJSON.
• Git-tracked datasets. Diffing a GeoJSON file in a PR review is genuinely useful; diffing a Shapefile is impossible.
• Cross-language toolchains. Every modern language has a fast JSON parser; not every language has a Shapefile reader.
• Hand-editing. Open in any text editor, tweak a coordinate, save. Try that with a binary .shp.

The 2025 recommendation

For new projects, the honest answer is: use neither. Use GeoPackage for desktop work (single file, spatial index, no field-name limits, multiple layers, Unicode by default), and GeoJSON for web work (universal browser support, plain text, RFC standard).

Reach for Shapefile only when an external constraint forces you to. The format is not dying — it's too widely deployed for that — but it stopped being the default sometime around 2018, when QGIS made GeoPackage its preferred native format and the OGC made GeoPackage a formal recommendation.

If you must convert between the two, our Shapefile to GeoJSON converter and GeoJSON to Shapefile converter handle the common cases. For batch work, ogr2ogr on the command line is your friend:

ogr2ogr -f GeoJSON output.geojson input.shp
ogr2ogr -f "ESRI Shapefile" output_dir input.geojson

Mind the field-name truncation when going GeoJSON → Shapefile, and assign a CRS explicitly if your data is not in WGS 84.