Why Is a Shapefile Made of Multiple Files?

A Shapefile is made of multiple files because the format stores different parts of the same geographic layer separately. The .shp file contains feature geometry, the .shx file indexes those geometries, and the .dbf file contains their attributes. Other companion files can add information such as the coordinate reference system, text encoding, spatial indexes, or metadata.

So if someone sends you only roads.shp, they have not necessarily sent you the complete Shapefile.

At minimum, the traditional format consists of three required files with the same base name:

roads.shp
roads.shx
roads.dbf

In practice, you will often also want:

roads.prj
roads.cpg

and you may encounter still more files depending on which software has worked with the dataset.

The important idea is that “Shapefile” refers to the dataset formed by these cooperating files, not just to the file ending in .shp.

The core files

The three required components divide geometry, indexing, and attributes between them.

• File: .shp; What it contains: Feature geometry; Required?: Yes

• File: .shx; What it contains: Index of feature geometry; Required?: Yes

• File: .dbf; What it contains: Attribute table; Required?: Yes

• File: .prj; What it contains: Coordinate reference system information; Required?: No, but often important

• File: .cpg; What it contains: Character encoding/code page information; Required?: No

• File: .sbn / .sbx or .qix; What it contains: Spatial indexes; Required?: No

• File: .xml / .shp.xml; What it contains: Metadata, depending on software; Required?: No

Current ArcGIS Pro documentation describes Shapefiles as being stored in three or more files with the same prefix in the same folder, with .shp, .shx, and .dbf as the required components.

What does the .shp file contain?

The .shp file contains the geometry of the features.

If the layer represents roads, this is where the line geometries are stored. If it represents administrative areas, the polygon coordinates are stored here. If it represents wells or schools, the point geometries are stored here.

Importantly, the .shp file does not contain the ordinary attribute table.

A feature might conceptually look like this:

Geometry: POINT (11.52 3.87)
Name: Example School
Type: Primary
Students: 420

The .shp component stores the geometry—not the Name, Type, or Students values. Esri's current documentation explicitly describes .shp as containing only feature geometry.

This is why copying only the .shp file can leave you with shapes but not the descriptive information that made those shapes useful.

What does the .dbf file contain?

The .dbf file contains the attributes.

DBF is the table format associated with dBASE, and the Shapefile format uses it to store one attribute record for each geographic feature.

A simplified table might look like:

• Record: 1; name: Example School; type: Primary; students: 420

• Record: 2; name: Another School; type: Secondary; students: 610

• Record: 3; name: Third School; type: Primary; students: 280

Those rows correspond to geometries stored separately in the .shp file.

The connection is based on record order. The first geometry corresponds to the first DBF row, the second geometry to the second row, and so on. Esri documents this as a one-to-one relationship based on record number.

That arrangement helps explain both the format's simplicity and some of its fragility: the geometry and attributes are separate physical files, but logically they belong to the same records.

It also explains several of Shapefile's well-known attribute limitations. Because attributes use the DBF model, field names are limited to ten characters in the conventional format, and the supported data types are much more restricted than in modern database-oriented formats. GDAL documents both the ten-character field-name constraint and the limited DBF field types.

What does the .shx file do?

The .shx file is the shape index.

Geometries in the .shp file can have different sizes. A point is small; a complex polygon containing thousands of vertices is much larger. Software therefore needs an efficient way to find the record it wants without repeatedly scanning the entire geometry file.

The .shx file stores information about the positions of feature records in the .shp file. ArcGIS describes it as the companion file that stores the position of individual feature IDs, while GDAL treats .shp, .shx, and .dbf together as the normal Shapefile set.

Conceptually:

.shx index

Feature 1 ───→ position of geometry 1 in .shp
Feature 2 ───→ position of geometry 2 in .shp
Feature 3 ───→ position of geometry 3 in .shp

The index does not contain another copy of the geometry. It helps software locate geometry records efficiently.

If a .shx file is missing, some software can reconstruct it from the .shp data—GDAL, for example, has an option to restore a missing or broken .shx file—but you should not rely on every application doing so. The .shx remains a required part of the conventional format.

What is the .prj file?

The .prj file normally stores the layer's coordinate reference system definition, usually as Well-Known Text (WKT).

For example, coordinates such as:

610000, 445000

cannot be interpreted reliably simply by looking at them. Software also needs to know which CRS gives those numbers geographic meaning.

The .prj sidecar can provide that information.

Esri describes .prj as the Shapefile component containing coordinate-system information, and GDAL reads the file when present to associate a spatial reference with the features.

Unlike .shp, .shx, and .dbf, however, .prj is not one of the three mandatory core files.

That means it is possible to receive a technically recognisable Shapefile without CRS information.

The geometry and attributes may still be present, but you now have a more difficult question:

What coordinate reference system were these coordinates actually created in?

If that information cannot be recovered elsewhere, the file has lost an important part of its geographic context. What Happens When a GIS File Has No CRS? treats that problem in more detail.

What does the .cpg file do?

The .cpg file can specify the character encoding used for text in the DBF attribute table.

That matters when attributes contain characters outside a simple ASCII range—for example accented characters or names written in other scripts.

Without reliable encoding information, one program may write text using one character encoding while another interprets the bytes using another. The result can be corrupted-looking text rather than the original names.

GDAL checks a .cpg file when determining the encoding of Shapefile attribute strings, falling back to encoding information stored in the DBF when necessary.

So .cpg is optional, but that does not mean it is irrelevant.

A Shapefile containing:

École publique d'Essos

may still have perfectly valid geometry if the encoding information is lost, while its text attributes become much harder to interpret correctly.

This is a good example of why “optional file” and “unimportant file” are not the same thing.

And what are .sbn, .sbx, and .qix?

These are examples of spatial index files.

Their purpose is different from .shx.

The .shx index helps locate individual geometry records inside the .shp file. A spatial index helps software answer geographic queries efficiently—for example:

Which features might intersect this map extent?

Rather than testing every feature in a large dataset, software can use the spatial index to narrow the candidates.

ArcGIS documents .sbn and .sbx as optional spatial-index components. GDAL can read Esri's .sbn/.sbx indexes and can also create and use .qix spatial indexes.

If these optional indexes disappear, the actual features and attributes are not necessarily lost. The main effect may instead be slower spatial access until an index is rebuilt.

That is quite different from losing the .shp or .dbf.

Why was the format designed this way?

The Shapefile format separates several responsibilities instead of placing an entire spatial layer inside one container.

The main file stores variable-length geometry records. The shape index provides direct access to those records. The DBF table provides the attributes using an existing tabular format. Additional sidecars can then add capabilities without changing the three-file core.

This architecture made sense for a relatively simple, file-based GIS format designed to store non-topological vector features efficiently and to make them accessible to different software implementations.

But it also reflects the era in which Shapefile was designed.

Modern formats can package substantially more structure into one container. A GeoPackage, for example, uses SQLite and can hold multiple vector layers, attributes, coordinate-system definitions, and other content inside one .gpkg database file.

That does not make a Shapefile inherently unusable. It explains why the experience of moving one can feel unusual today.

The broader trade-off between the two formats is covered in GeoPackage vs Shapefile.

What happens if one of the files is missing?

It depends on which one.

Missing .shp

The geometry is gone.

You may still have a DBF table of attributes, but you no longer have the feature shapes that make the dataset spatial.

Missing .dbf

The geometry may physically remain in the .shp, but the conventional Shapefile dataset has lost its attribute table and one of its required components.

A GIS reader may refuse the incomplete dataset or expose only limited geometry behaviour depending on the software.

Either way, fields such as names, classifications, identifiers, or measurements stored in the DBF are no longer available.

Missing .shx

The geometry index is gone.

Some tools can reconstruct it, but the normal Shapefile set is incomplete. GDAL, for example, can optionally regenerate a missing .shx; that recovery behaviour should not be assumed across all applications.

Missing .prj

The layer may still open and show its features, but its CRS information is no longer being supplied by that sidecar.

If the CRS is known from another authoritative source, it can potentially be assigned again. If it is unknown, identifying it becomes a separate data-quality problem.

Missing .cpg

The layer can still contain geometry and attributes, but character encoding may be ambiguous. Text can consequently appear incorrectly in software that guesses the encoding differently.

Missing spatial indexes

The data is generally still there. Some spatial operations or display queries may simply become less efficient until the indexes are recreated.

So “a Shapefile file is missing” is not one kind of failure. The consequence depends on the responsibility that file carried.

Why do all the files need the same name?

A Shapefile's components are associated through their base filename.

For example:

schools.shp
schools.shx
schools.dbf
schools.prj
schools.cpg

together describe the same logical dataset.

If you instead have:

schools.shp
schools_index.shx
school_attributes.dbf

software generally cannot infer that those differently named files are meant to belong together.

Esri explicitly requires the components to use the same prefix.

This is why casually renaming individual files inside a Shapefile set is dangerous. Rename the dataset as a unit, keeping the common basename consistent across its components.

Should you send a Shapefile as a ZIP?

Usually, yes.

A ZIP archive solves an awkward distribution problem: even though the Shapefile is one logical dataset, operating systems and email clients see several separate files.

Packaging them gives you:

roads.zip

while preserving inside it:

roads.shp
roads.shx
roads.dbf
roads.prj
roads.cpg

This reduces the chance that someone downloads only the .shp or forgets one of the sidecars.

ZIP does not turn the Shapefile into a different geospatial format. It is simply a convenient package around the component files.

Modern software may even read zipped Shapefiles directly. GDAL, for example, supports ZIP-packaged Shapefile datasets including .shz and .shp.zip forms.

If you are distributing a Shapefile manually, packaging the complete set is much safer than asking the recipient to collect each component independently.

How many files does a Shapefile actually need?

The safest answer is:

Three files form the required core, but a useful Shapefile often contains more.

At minimum:

dataset.shp
dataset.shx
dataset.dbf

For geographic work, you will commonly also want:

dataset.prj

And when text encoding matters:

dataset.cpg

You might also see spatial indexes, attribute indexes, metadata files, or software-specific sidecars.

So there is no meaningful rule that a Shapefile should contain exactly three, four, or five physical files.

Instead, ask what information needs to travel with the dataset.

That is also why the four-format comparison in GeoJSON vs Shapefile vs GeoPackage vs KML treats Shapefile as a multi-file dataset rather than comparing .shp directly with .geojson, .gpkg, or .kml.

Those extensions do not represent equivalent container structures.

Keep the dataset, not just the .shp

The confusion around Shapefiles largely comes from their name.

A file called:

boundaries.shp

looks as though it should contain the complete geographic layer.

It does not.

The geometry lives there, but its attributes normally live in boundaries.dbf, its geometry index in boundaries.shx, its coordinate-system information may live in boundaries.prj, and its text encoding may be clarified by boundaries.cpg.

Together, those files make the useful dataset.

So when copying, uploading, archiving, or sending a Shapefile, the practical rule is simple:

move the components together.

If someone asks you for “the .shp”, it is usually worth confirming whether they actually mean the complete Shapefile.

Most of the time, they do.

References

1. Esri — ESRI Shapefile Technical Description. The original technical description of the Shapefile structure and its geometry, index, and attribute components.

2. ArcGIS Pro — Geoprocessing Considerations for Shapefile Output. Current documentation identifying .shp, .shx, and .dbf as required components and describing optional index, CRS, and metadata files.

3. GDAL — ESRI Shapefile / DBF Driver. Documents Shapefile component handling, PRJ and CPG interpretation, spatial indexing, DBF limitations, ZIP support, and optional reconstruction of missing SHX files.