What is a Shapefile? The complete guide to SHP files

If you work with any kind of geospatial data, you have almost certainly encountered a Shapefile. It is the most widely distributed vector GIS format on the planet — government agencies, universities, and data portals have been publishing Shapefiles for over 25 years. And yet most people who use them daily could not explain exactly what a Shapefile is or why it works the way it does.

This guide covers everything: what files make up a Shapefile, what data it can hold, why it has those frustrating limitations, and when you should convert to something more modern.

What is a Shapefile?

A Shapefile is a geospatial vector data format created by Esri (the company behind ArcGIS) in 1998. It stores the geometry of geographic features — points, lines, and polygons — along with a table of attributes describing each feature. A city boundary, a river network, a dataset of hospitals: all of these can be represented as a Shapefile.

Despite its name, a Shapefile is not a single file. It is a collection of at least three files that must always be kept together. This is the first thing that confuses people who are new to GIS.

The files that make up a Shapefile

Every Shapefile consists of mandatory and optional component files, all sharing the same base name (e.g. roads):

• .shp — Geometry. The main file. Contains the actual geographic shapes: points, polylines, or polygons stored in binary format.
• .dbf — Attributes. A dBASE III database table. Each row corresponds to a feature in the .shp file, and each column is an attribute (name, population, area, etc.).
• .shx — Index. A positional index that links each record in the .shp file to its corresponding row in the .dbf. Without this file, software cannot efficiently read individual features.
• .prj — Projection (optional but important). Defines the coordinate reference system (CRS) — e.g. WGS 84, UTM Zone 32N. Without this file, GIS software has to guess the CRS, which often leads to data appearing in the wrong place on a map.
• .cpg — Character encoding (optional). Specifies how text in the .dbf is encoded (e.g. UTF-8). Without this file, accented characters and non-Latin text may display incorrectly.

If someone emails you only the .shp file, you cannot open it. This is why Shapefiles are almost always distributed as ZIP archives containing all the component files together.

What geometry types does a Shapefile support?

A Shapefile can store one of the following geometry types — but only one type per file:

• Point — single coordinate pairs (e.g. city centres, GPS waypoints)
• Multipoint — a set of points as one feature
• Polyline — one or more connected line segments (e.g. roads, rivers)
• Polygon — closed areas with optional holes (e.g. country boundaries, lake outlines)
• PointZ / PolylineZ / PolygonZ — 3D variants with Z (elevation) values
• PointM / PolylineM / PolygonM — features with a measure value (M) alongside geometry

If you have a dataset mixing points and polygons, you cannot store it in a single Shapefile. You need two separate files — one for each geometry type. This is a real limitation in practice.

The attribute table and the 10-character limit

The .dbf file is a legacy dBASE database format from the early 1980s. It stores attribute data as a flat table — rows are features, columns are attributes. You can have many columns, each storing text, integers, floating-point numbers, or dates.

The notorious limitation: field names are limited to 10 characters. This is a hard constraint from the dBASE III spec. A field called population_2023 gets silently truncated to something like population_ when written to a Shapefile. Worse, truncation can cause name collisions that corrupt data silently.

Other .dbf limitations worth knowing:

• Text fields are capped at 254 characters
• No native support for boolean (true/false) values
• Date fields exist but time fields do not — storing datetimes requires workarounds
• The entire .dbf file cannot exceed 2 GB

Other Shapefile limitations

Beyond the field name problem, there are several other constraints that matter for larger projects:

• 2 GB file size limit. The .shp file cannot exceed 2 GB. For datasets with millions of features or high-resolution geometry, this is a hard stop.
• No topology. A Shapefile stores independent features with no knowledge of which polygons share edges or which lines connect at nodes. Topological errors (slivers, gaps) are common and go undetected.
• No multiple layers. One Shapefile = one geometry type = one layer. A project with ten layers means ten sets of files.
• No embedded metadata standard. There is no standardised way to embed CRS information, data lineage, or update history inside a Shapefile. The .prj file is a convention, not a requirement.

Why is Shapefile still so common?

Given all these limitations, why do organisations still use Shapefile in 2026? A few reasons:

• Universal compatibility. Every GIS tool — QGIS, ArcGIS, GRASS, PostGIS, R, Python — can read and write Shapefile. This is not true of newer formats.
• Institutional inertia. Government agencies have been publishing Shapefiles since the late 1990s. Changing the format of a public data portal is expensive and slow.
• It just works for most use cases. For a dataset of 50,000 polygons with a handful of short attribute names, Shapefile is perfectly adequate. The limitations only bite at scale or in complex projects.

How to open a Shapefile

The most common ways to open a Shapefile:

• QGIS (free, cross-platform) — drag and drop the .shp or .zip
• ArcGIS Pro / ArcMap — Add Data → navigate to the .shp
• Python / geopandas — geopandas.read_file("file.shp")
• R / sf — sf::st_read("file.shp")
• ogr2ogr — inspect with ogrinfo file.shp

If you received a ZIP, extract it first so the .shp, .dbf, and .shx files are in the same folder — or upload the ZIP directly to Maparz and let us handle extraction automatically.

When should you convert away from Shapefile?

Consider converting your Shapefile to a different format when:

• Your field names are longer than 10 characters. Convert to GeoPackage or GeoJSON, which have no field name limit.
• You need to share data on the web or in a GitHub repo. Convert to GeoJSON, which renders natively in browsers and GitHub.
• Your file is approaching 2 GB. GeoPackage and FlatGeobuf handle arbitrarily large datasets.
• You need multiple layers in one file. GeoPackage supports multiple layers in a single .gpkg file.
• You are delivering to a CAD workflow. Convert to DXF for AutoCAD, BricsCAD, or QCAD.
• You need Google Earth compatibility. Convert to KML or KMZ.