What Is a Shapefile?

A shapefile is a vector GIS format introduced by Esri in the 1990s for storing geographic features such as points, lines, and polygons together with tabular attributes.

Despite its singular name, a shapefile dataset is not usually one physical file. It is a coordinated set of files that share the same base name. That design is one reason shapefiles remain widely compatible—and one reason they are easy to damage when files are copied or emailed incompletely.

The format is old, but it is not obsolete in the sense of being unreadable or unsupported. Shapefiles remain common in government portals, legacy workflows, desktop GIS, field data exchange, and organisations that need a denominator almost every GIS tool can open.

What a shapefile stores

A shapefile stores one vector feature class. All records in the dataset use a compatible geometry type, such as points, polylines, or polygons.

Each feature also has an attribute record, so a polygon dataset of administrative areas might contain fields for name, code, population, or category alongside the geometry.

The important limitation is that the geometry and attributes are not packaged in one modern database container. They are distributed across companion files whose roles are defined by the format.

The existing Geobble guide Why Is a Shapefile Made of Multiple Files? owns that file-by-file anatomy. It explains the roles of .shp, .shx, .dbf, .prj, and other companions in detail rather than duplicating them here.

Why shapefiles became so widespread

The format succeeded because it was simple, documented, and implemented across a huge amount of GIS software. That compatibility still matters: if you need to exchange a straightforward vector layer with an unknown desktop GIS environment, shapefile support is extremely likely.

The format also separates the geometry from any proprietary project file or database server. A shapefile can be copied as a dataset and opened independently by many tools.

Those strengths explain why the format persists even though newer formats solve many of its limitations more cleanly.

The limitations are structural, not merely aesthetic

Shapefile constraints affect real workflows.

Field names and attribute types

The attribute table is based on dBASE, so field naming and typing are more limited than in modern databases and columnar formats. Long, descriptive field names may be truncated or renamed during export, while some data types may be converted into less expressive representations.

Text encoding

Character encoding can become ambiguous when the necessary metadata are absent or ignored. Names containing accented or non-Latin characters can therefore become corrupted between systems.

Nulls and richer schemas

The format does not provide the same schema richness as formats such as GeoPackage or Parquet. Applications may differ in how they represent nulls, dates, large numeric values, or unsupported field types during conversion.

One layer per dataset

A shapefile represents one feature layer, meaning that a project containing roads, buildings, administrative boundaries, and facilities requires separate shapefile datasets rather than one self-contained container.

Multiple companion files

Copying only the .shp file is not equivalent to copying the dataset. Losing the index, attribute table, or CRS metadata can leave the geometry incomplete or hard to interpret.

Shapefile versus GeoPackage

For many new desktop GIS workflows, GeoPackage is a more capable interchange container. It can store multiple vector tables, attributes, and tile data inside one SQLite database file, with a standardised schema and extensibility model.

That does not make every shapefile conversion automatically beneficial. If a receiving system explicitly requires shapefile, compatibility can outweigh format elegance. If the source has already been delivered as shapefile and no information is being lost, keeping the source unchanged can also preserve provenance.

The useful distinction is between source format, working format, and delivery format. They do not have to be identical.

Do not confuse format conversion with data improvement

Converting a shapefile to GeoPackage, GeoJSON, or GeoParquet changes representation; it does not make inaccurate geometry more accurate, add missing metadata, repair invalid features, or resolve an unknown CRS.

Conversion can even lose information if field types, CRS metadata, encodings, dimensions, or identifiers are not mapped carefully.

What Information Can Be Lost When Converting GIS Formats? covers that risk directly.

When a shapefile is still reasonable

A shapefile remains a defensible choice when:

the receiving system explicitly expects it;
maximum compatibility with older GIS software is important;
the dataset is a simple vector layer whose schema fits the format;
the dataset is being preserved in the format in which it was supplied;
the limitations are understood and tested during export.

For new multi-layer, multilingual, cloud-native, or schema-rich workflows, a newer format will often be easier to manage.

The key is not to reject shapefiles because they are old, but to avoid asking the format to carry information it was never designed to preserve.