Convert Shapefile to GeoJSON: The Complete Guide

You have a Shapefile and you need it as GeoJSON. Maybe you're loading map data into a web app, maybe an API expects JSON, maybe you just want one file instead of five. The conversion itself is fast. What trips people up is usually something that happened before the conversion: a missing file in the bundle, coordinates in an unexpected system, or encoding issues that corrupt the text.

This article covers three ways to do the conversion, and the things worth checking before you assume it worked correctly.

What you're working with

A Shapefile is not one file. It's a bundle of files that only work together. At minimum, a working Shapefile needs:

• .shp: the geometry (the actual points, lines, and polygon outlines)
• .dbf: the attributes (the column data attached to each entry)
• .shx: an index file (tells software how to navigate the .shp quickly)

It should also have:

• .prj: the coordinate system declaration

And may include:

• .cpg: specifies the text encoding for the .dbf

The What Is a Shapefile article explains why the format works this way and what each file does.

GeoJSON is the opposite: everything in a single text file. Geometry, properties, and coordinate system (always WGS 84, the standard GPS system) all together.

The conversion from Shapefile to GeoJSON is mostly lossless. The main thing that survives perfectly is everything: geometry, properties, and values. What you lose is nothing meaningful, assuming the Shapefile was well-formed to begin with.

Method 1: A one-click web converter

The fastest route for a one-off job.

1. ZIP your Shapefile bundle. All the files (.shp, .dbf, .shx, .prj) must be inside, with matching base names.
2. Go to Georaf.
3. Drop the ZIP onto the upload zone.
4. Choose GeoJSON as the output.
5. Click Convert. Download.

Georaf handles the multi-file bundle automatically. You don't need to tell it which file is which. It finds the .shp and the siblings, reads the .prj for the coordinate system, and handles the conversion in one step.

The reason to use a web converter for a single file is the same as always: the work to install a local tool is usually more than the work to convert the file. If you do this once a month, Method 1 is the right answer.

Beyond convenience, Georaf shows you what it found in the file: how many entries, what columns, whether anything looks broken. If the .prj is missing, it will tell you rather than silently producing coordinates that might be wrong. If some entries have invalid geometry, you'll see them flagged. Most converters don't surface any of this.

Method 2: ogr2ogr (command-line)

For batch conversion or scripted workflows, ogr2ogr is the standard tool. It ships with GDAL, which is also what powers QGIS under the hood.

Install:

brew install gdal
# or on Ubuntu/Debian
sudo apt install gdal-bin

Convert a single Shapefile:

ogr2ogr -f GeoJSON output.geojson input.shp

Note: output comes before input. That's how ogr2ogr works. It's a common mistake on the first try.

You can point ogr2ogr at the .shp file directly. It will find the .dbf, .shx, and .prj automatically, as long as they're in the same folder with matching names.

To convert all Shapefiles in a directory:

for f in *.shp; do
  ogr2ogr -f GeoJSON "${f%.shp}.geojson" "$f"
done

If you need to reproject the coordinates during conversion (for example, if the source is in a local projected system and you need standard WGS 84 output):

ogr2ogr -f GeoJSON -t_srs EPSG:4326 output.geojson input.shp

EPSG:4326 is the code for WGS 84, the coordinate system GeoJSON officially uses. See the EPSG:4326 vs 3857 article for more on what those numbers mean.

Good for: bulk conversion, automation, scripted pipelines.

Not good for: knowing whether the output is correct. ogr2ogr converts quietly. If the .prj was wrong, the coordinates will be wrong, and the tool won't say anything.

Method 3: Python with geopandas

If conversion is one step in a larger workflow, doing it in Python keeps everything in one place.

import geopandas as gpd

# Read the Shapefile (point at the .shp file)
gdf = gpd.read_file('input.shp')

# Check the coordinate system
print(gdf.crs)

# Reproject to WGS 84 if needed
if gdf.crs != 'EPSG:4326':
    gdf = gdf.to_crs('EPSG:4326')

# Write out as GeoJSON
gdf.to_file('output.geojson', driver='GeoJSON')

The print(gdf.crs) line is worth including. It tells you what coordinate system geopandas found in the .prj file. If it prints None, the .prj is missing and you'll need to figure out the correct system from context before proceeding.

Good for: data pipelines, any case where you need to clean, filter, or transform the data alongside the conversion.

Not good for: a single file on a deadline. Standing up a Python environment for one conversion takes longer than dragging the file onto a web converter.

What to watch for

Missing .prj file

This is the most common problem. Without a .prj, the tool doing the conversion doesn't know what coordinate system the numbers in .shp refer to. Most tools will assume WGS 84 and proceed without warning. If the source data was in a local projected system (common with survey data, engineering drawings, or government cadastral data), your entries will end up in the wrong place, sometimes thousands of kilometers from where they should be.

If your entries are showing up in the wrong country, a missing or mismatched .prj is almost certainly the cause. The coordinate mismatch article explains how to diagnose it, and the EPSG:4326 vs 3857 article covers the most common systems you'll encounter.

Text encoding issues

The .dbf file stores your text data. Old Shapefiles sometimes used non-UTF-8 encodings, especially files from regions with non-ASCII characters in place names (accented letters, Cyrillic, Chinese, etc.). The .cpg file, when present, tells software which encoding to use.

If the .cpg file is missing and the source was in a non-standard encoding, your text attributes may come out garbled in the GeoJSON. You'll see unexpected characters in place of special letters.

To fix it in Python:

gdf = gpd.read_file('input.shp', encoding='latin-1')
# or encoding='cp1252', depending on the source system

You'll need to know or guess the original encoding. Latin-1 and Windows-1252 are the most common for Western European data. If you received the Shapefile from someone, ask them which system it was created on.

The multi-file requirement

You can't convert a Shapefile if the bundle is incomplete. The .shp alone is just the geometry, with no properties. The .dbf alone is just a table, with no geography. You need both, plus the .shx index.

If someone sent you only the .shp file, you'll need to ask for the full bundle as a ZIP. See What Is a Shapefile for why the format is split this way.

Very long field names

Shapefile field names are capped at 10 characters. This means a GeoJSON you convert to Shapefile and then back to GeoJSON will have truncated column names compared to the original. If you're round-tripping data, check for this. It's not a conversion bug, it's a Shapefile limit.

So which method?

For most people who land on this article, Method 1 is the right call. The other two are for people converting files programmatically, and those people already know it.

Wrapping up

Shapefile to GeoJSON is one of the more forgiving conversions in geo-data. The geometry almost always comes through cleanly. The things that go wrong are usually upstream problems, a missing .prj, a non-standard encoding, an incomplete bundle, and a good converter will flag them instead of silently producing something that looks fine but isn't.

If you want to open a Shapefile without installing desktop GIS software at all, the open without QGIS article covers your options. If you need to understand which format to use for your situation going forward, GeoJSON vs Shapefile has the decision table.

For the conversion itself, drop your ZIP on Georaf. You'll have GeoJSON in under a minute, with a plain-English summary of what's in the file.