GeoJSON, KML, Shapefile, GeoTIFF — Which Format for Which Job

Every GIS project starts with the same question and nobody wants to ask it out loud: what format should this be in? You download data from one source, try to load it in a tool, get an error, find out you need to convert it, convert it, lose half the attributes, and spend an hour figuring out why.

This happens because GIS has accumulated formats over 40 years of competing standards, different use cases, and tools that never fully agreed on conventions. The formats aren't interchangeable — they were designed for different things, and treating them as equivalent is where most of the friction comes from.

Here's what each major format is actually for and when to use it.

The Main Formats at a Glance

GeoJSON — The Web Mapping Standard

GeoJSON is what you want when you're building anything on the web. It's supported natively by Leaflet, Mapbox GL JS, OpenLayers, D3, Turf.js, deck.gl, and virtually every web mapping API. GitHub automatically renders GeoJSON files as maps when you view them in a repository. It's a proper JSON object — no binary, no secondary files, parse it with JSON.parse().

Use GeoJSON when:

• Building a web map with Leaflet, Mapbox, or similar
• Sending geographic data from/to a REST API
• Working with small-to-medium vector datasets (points, lines, polygons)
• You need human-readable, version-controllable geographic data
• Storing data in MongoDB, PostGIS, or any modern database with GeoJSON support

The main gotcha: GeoJSON coordinates are [longitude, latitude] — not [latitude, longitude]. This trips up everyone at least once. The spec follows mathematical [x, y] convention where x is the east-west axis. If your points appear in the ocean when they should be on land, you have them backwards.

GeoJSON's other limitation is size. It's text-based with no compression. A large polygon dataset — national boundaries, census tracts, landcover — can easily hit 50MB+ as GeoJSON. For those cases, look at TopoJSON or GeoPackage.

KML — Google's Format

KML was created by Keyhole Inc. (acquired by Google in 2004) as the native format for Google Earth. It became an OGC standard in 2008. KML's main strength over GeoJSON is its rich styling support — you can embed colors, icon URLs, line widths, polygon fill patterns, and camera angles directly in the file. A KML file can be a complete self-contained presentation layer, not just raw geometry.

Use KML when:

• Sharing data that needs to be viewed in Google Earth
• Importing data into Google Maps (My Maps feature)
• You need styled features where appearance is part of the data
• Sending data to non-technical users who'll open it by double-clicking
• Working with legacy enterprise GIS that expects KML/KMZ

KMZ is just a zipped KML file — same structure, compressed. Most tools that accept KML also accept KMZ. Use KMZ for large files or when packaging KML with icon images.

What KML loses in conversion to GeoJSON: Style information (colors, icons, line widths), folder/layer hierarchy, camera/LookAt views, network links that load data dynamically, ground overlays, and timestamps. The geometry and flat text properties survive; everything visual does not.

Shapefile — The Legacy Standard

Shapefile is Esri's format from the early 1990s. It's been the dominant desktop GIS format for three decades, which means virtually every government data portal, census bureau, and environmental agency still publishes data in Shapefile format. It's also the thing everyone loves to complain about.

A "Shapefile" is actually a minimum of three files that must stay together:

• .shp — the geometry (coordinates)
• .dbf — the attributes (dBASE III format from 1983)
• .shx — the shape index

Often accompanied by .prj (projection/CRS info), .cpg (character encoding), and others. Emailing or uploading a Shapefile and having the recipient unable to open it because they only got the .shp is a rite of passage in GIS work.

Shapefile's limitations are well-documented:

• Column names truncated to 10 characters — population_density becomes population or worse
• No date/time type — dates are stored as strings
• File size limit of 2GB per .shp file
• No NULL distinction — empty values are ambiguous
• No native support for multi-layer datasets
• Encoding headaches — attribute encoding is often wrong or unspecified

Use Shapefile when: You're receiving data from a government source that only provides this format, or delivering data to a client/agency that requires it. Otherwise, convert it to something better (GeoPackage, GeoJSON, PostGIS) as early in your workflow as possible.

GeoTIFF — Raster Data with Spatial Coordinates

Everything discussed so far is vector data — discrete geometries (points, lines, polygons). GeoTIFF is raster data — a grid of pixels where each pixel represents a value at a location. Satellite imagery, elevation models (DEMs), land cover classification, temperature grids, NDVI — these are all raster datasets.

GeoTIFF embeds CRS (coordinate reference system) information and georeferencing metadata directly in the TIFF file using TIFF tags. This means the file knows exactly where it is on Earth without a separate metadata file. It can store multiple bands (RGB, multispectral, hyperspectral) in a single file.

Use GeoTIFF when:

• Working with satellite imagery (Sentinel, Landsat, commercial providers)
• Elevation data — DEMs (Digital Elevation Models)
• Continuous field data — temperature, precipitation, population density grids
• Results of spatial analysis that produce gridded output

Cloud Optimized GeoTIFF (COG) is a GeoTIFF organized so HTTP range requests can efficiently access just part of the file. This allows streaming access to large raster datasets stored on cloud storage without downloading the entire file — it's the standard for publishing satellite imagery in modern geospatial APIs.

GPX — GPS Tracks and Routes

GPX (GPS Exchange Format) is an XML schema designed specifically for GPS data. Every fitness tracker, hiking app, and GPS device exports GPX. It supports three data types: waypoints (single named points), routes (planned paths), and tracks (recorded movement with timestamps).

Tracks in GPX are time-stamped sequences of coordinates — this is what your running watch exports when you finish a run. The temporal dimension is baked into the format in a way that GeoJSON doesn't natively support.

Use GPX when: You're working with GPS tracks from fitness apps (Garmin, Strava, AllTrails), transferring routes to/from a dedicated GPS device, or any workflow where you need timestamped movement data.

Converting GPX to GeoJSON loses the timestamps unless you specifically map them to GeoJSON properties. GDAL/OGR handles this conversion correctly; simple text-based converters often drop the time data.

TopoJSON — Smaller Polygons Through Topology

TopoJSON is a GeoJSON extension created by Mike Bostock (D3.js author) that encodes topology — adjacent polygons share boundary arcs rather than each polygon storing its own duplicate coordinates. The result is significantly smaller files for datasets with shared boundaries, like country borders, census tracts, or administrative divisions.

A GeoJSON world countries file might be 700KB. The same data as TopoJSON can be 90KB — roughly 87% smaller. For D3 visualizations loading data over the web, this matters. The trade-off is that TopoJSON isn't as universally supported as GeoJSON — Leaflet doesn't read it natively (you need a plugin), and many GIS tools don't understand it at all.

Use TopoJSON when: Building D3.js data visualizations where file size affects load performance, specifically for datasets with many shared boundaries (choropleth maps, administrative boundaries, census data).

CSV — The Lowest Common Denominator

A CSV with latitude and longitude columns is technically a spatial dataset. It's universally readable by every tool that exists. For point data — store locations, event positions, sensor readings — a CSV is often the right choice precisely because of its simplicity.

CSV with WKT (Well-Known Text) geometry columns extends this to lines and polygons: a column like POLYGON((0 0, 1 0, 1 1, 0 1, 0 0)) encodes geometry in readable text. QGIS and many GIS tools can read CSV with WKT columns directly.

The limit: No projection metadata, no attribute type information, no multi-layer support, and large files can be slow to parse. For point data under a few hundred thousand records, CSV is fine. Beyond that, use a proper spatial format.

Format Comparison Table

GDAL: The Universal Translator

Nearly every GIS conversion tool is built on top of GDAL/OGR — the Geospatial Data Abstraction Library. QGIS uses it. ArcGIS uses it. The command-line tool ogr2ogr is the most powerful format converter available: it converts between 80+ vector formats, handles coordinate system transformations, filters by attribute, and clips by bounding box in a single command.

# Convert Shapefile to GeoJSON
ogr2ogr -f GeoJSON output.geojson input.shp

# Convert KML to GeoJSON
ogr2ogr -f GeoJSON output.geojson input.kml

# Convert GeoJSON to GeoPackage
ogr2ogr -f GPKG output.gpkg input.geojson

# Reproject from WGS84 to Web Mercator
ogr2ogr -f GeoJSON -t_srs EPSG:3857 output.geojson input.geojson

For browser-based conversion without installing GDAL — paste the data, convert, and download — use the tool below.

The Decision Framework

The right format depends on three questions:

1. Who receives the data? If it's a developer building a web map → GeoJSON. If it's a non-technical user who'll double-click it → KML. If it's a government agency's legacy system → Shapefile.
2. What data type is it? Discrete features (points, lines, polygons) → vector formats. Continuous gridded values (elevation, imagery, analysis results) → GeoTIFF. GPS tracks with timestamps → GPX.
3. What needs to survive the transfer? If visual styling matters, KML preserves it. If topology matters (shared boundaries, area calculations), GeoPackage or TopoJSON. If just geometry and attributes, GeoJSON or GeoPackage are both fine.

The practical shortcut: GeoJSON for the web, GeoPackage for files, GeoTIFF for rasters, Shapefile only when forced to. That covers 90% of GIS workflows.