What is the difference between shapefile, GeoPackage and GeoJSON?

A shapefile is a multi-file vector format from the early 1990s with strict limits. GeoPackage is a single SQLite file holding multiple layers, indexes and styles. GeoJSON is a plain-text, web-native format that always uses WGS84 longitude-latitude under RFC 7946.

Why is the shapefile 10-character field name limit a problem?

Shapefile attribute names are truncated to 10 characters, so descriptive columns like 'concentration_ppm' become 'concentrat' and may collide with other truncated names, silently corrupting your schema during export.

Is GeoPackage better than shapefile?

For most modern desktop and exchange work, yes. GeoPackage has no field-name truncation, no 2 GB size cap, full Unicode, multiple layers per file and built-in spatial indexing. Shapefile only wins where a legacy tool requires it.

When should I use GeoJSON instead of GeoPackage?

Use GeoJSON for web maps, APIs and small, human-readable exchanges. It is verbose and slow for large datasets, so above a few thousand complex features prefer vector tiles or a database delivery.

Shapefile vs GeoPackage vs GeoJSON

The short answer

For new work, GeoPackage is the sensible default desktop and exchange format, GeoJSON is the right choice for web maps and APIs, and shapefile should be reserved for cases where a downstream tool genuinely demands it. The shapefile is not "wrong," but it carries three-decade-old constraints — a 10-character field-name limit, a 2 GB per-component cap, one geometry type per file, and a multi-file structure that breaks when transferred incompletely — that cause silent data loss. GeoPackage removes all of those; GeoJSON trades efficiency for universal web readability.

What each format actually is

Shapefile

A shapefile is not a file but a set of files sharing a base name. The mandatory three are .shp (geometry), .shx (geometry index) and .dbf (attributes, a dBASE table). Practically you also need .prj (the CRS in WKT) and often .cpg (the attribute encoding). Lose the .prj and the data is positionally meaningless until someone guesses the CRS; lose the .dbf and you have geometry with no attributes. It is the Esri format from 1993, still ubiquitous because everything reads it.

GeoPackage

GeoPackage (.gpkg) is an OGC standard built on a single SQLite database file. One .gpkg can hold many vector layers, raster tiles, attribute tables, spatial indexes (R-tree) and layer metadata, all in one portable file. Because it is SQLite, you can open it with any SQLite client and query it with SQL. It is the format the OGC and QGIS now recommend as the shapefile successor.

GeoJSON

GeoJSON (.geojson / .json) is a text-based format defined by RFC 7946. It is human-readable, trivially parsed in JavaScript, and the native currency of web maps and many APIs. RFC 7946 mandates WGS84 longitude-latitude (EPSG:4326) with coordinates in lon, lat order — a frequent source of "my points are in the ocean" bugs when someone supplies lat, lon. It has no built-in index and balloons in size, so it is poor for large or heavy-geometry datasets.

The constraints that bite in practice

Concern	Shapefile	GeoPackage	GeoJSON
Field name length	10 chars (truncated)	Unlimited	Unlimited
Max size	~2 GB per `.shp`/`.dbf`	Effectively unlimited	Limited by memory/parser
Layers per file	One	Many	One feature collection
Geometry types per layer	One	One (but many layers)	Mixed allowed
CRS	Any (in `.prj`)	Any	WGS84 lon/lat only
Encoding	dBASE, often legacy	UTF-8	UTF-8
Null vs zero	Cannot store true NULL well	Proper NULL	Proper null
Date/time	Date only, no time	Full datetime	String (ISO 8601)

The field-name truncation is the quiet killer. Export a layer with columns sample_id, concentration_ppm and concentration_pct to shapefile and you get sample_id, concentr_1, concentr_2 — names mangled and reordered. The NULL problem matters in geology: a shapefile cannot cleanly distinguish "assay value is zero" from "assay not measured," because the .dbf tends to fill blanks with 0. GeoPackage stores a real NULL.

Decision guide

GeoPackage when you are editing in QGIS/ArcGIS, exchanging multi-layer projects, archiving, or want one tidy file with indexes and long field names.
GeoJSON for web maps, Leaflet/MapLibre layers, APIs, and small, diff-friendly, version-controlled vector data.
Vector tiles (MBTiles/PMTiles) or PostGIS when data is large, shared by many users, or productised — GeoJSON does not scale and a single GeoPackage is not a concurrent multi-user database.
Shapefile only when a recipient's software cannot read anything else.

Conversions with ogr2ogr

ogr2ogr (part of GDAL/OGR) is the reliable, inspectable way to convert — far safer than repeated menu exports.

Shapefile to GeoPackage, fixing encoding:

ogr2ogr -f GPKG output.gpkg input.shp \
  -nln samples -lco SPATIAL_INDEX=YES \
  --config SHAPE_ENCODING UTF-8

GeoPackage layer to GeoJSON in correct WGS84 lon/lat:

ogr2ogr -f GeoJSON samples.geojson output.gpkg samples \
  -t_srs EPSG:4326 -lco RFC7946=YES -lco COORDINATE_PRECISION=6

The RFC7946=YES option enforces lon/lat order and the standard's rules; COORDINATE_PRECISION=6 trims coordinates to about 0.1 m precision and shrinks the file. Going the other way, push GeoJSON into PostGIS:

ogr2ogr -f PostgreSQL "PG:dbname=geo user=gis" samples.geojson \
  -nln public.samples -lco GEOMETRY_NAME=geom -nlt PROMOTE_TO_MULTI

PROMOTE_TO_MULTI avoids the common failure where a layer mixes Polygon and MultiPolygon.

Inspecting before you trust a conversion

Run ogrinfo -so output.gpkg samples to read the summary without dumping every feature: it shows geometry type, feature count, CRS and the field schema. Check that field names are intact, the CRS is what you expect, and the feature count matches the source. For GeoJSON, open it in a text editor and confirm coordinates are in lon, lat order and the crs member (if present) is not contradicting RFC 7946.

Common mistakes and why they happen

Sending only the .shp. Recipients get geometry with no attributes or no CRS because the sibling files were left behind; shapefiles travel as a set or zip.
Assuming export success means clean data. A successful shapefile export can have truncated names, lost time components and zeros standing in for NULLs — all without an error.
Lat/lon order in GeoJSON. RFC 7946 is lon, lat; tools that emit lat, lon put features in the wrong hemisphere. Always verify with one known point.
Using GeoJSON for heavy analytics. A 200 MB GeoJSON will crawl in a browser and may exceed parser limits; tile it or move it to PostGIS.
Encoding mismatch. Accented or non-Latin attributes turn to mojibake when a shapefile's .cpg/encoding is wrong. GeoPackage's UTF-8 default avoids this.

Bathyl perspective

We treat format choice as a delivery decision, not a default. A dataset is finished when the recipient can open, query, publish and maintain it without losing field names, NULLs or position — so we ship GeoPackage for analysts, GeoJSON or tiles for the web, and document the CRS, schema and source with every handoff.