Missing .shx or .dbf: Why the Shapefile Won't Open (and What Each File Does)
Three files are the Shapefile: .shp, .shx and .dbf. Everything else with the same base name (.prj, .cpg, .sbn, .qix, .shp.xml) is a sidecar. When "the Shapefile won't open", one of the three is missing, and which one decides what you see: no .shx and GDAL refuses while the browser opens the file as if nothing happened; no .dbf and everything opens with zero attributes and no warning; no .shp and there is nothing to open. Below, what each file is, whether you can rebuild it, and what the shapefile-viewer and ogrinfo say when it is missing.
Tested on 16 September 2026 against the live shapefile-viewer at static-page-tools@442f8d8 and GDAL 3.13.3 "Iowa City", on IBGE's 2022 state boundaries (27 polygons, five fields), dropped as a zip and as loose files. The "What is a Shapefile?" section of the Shapefile guide describes each file byte by byte; this post is about what breaks.
One paragraph per file
.shp is the geometry: every record is a shape type code followed by coordinates. Mandatory, because it is the data, and not regenerable from anything else. In the browser it is the only file that must exist.
.shx is a fixed-width index: for each record, its byte offset into the .shp. The 1998 specification calls it mandatory and GDAL treats it that way; the browser never reads it (the shpjs parser walks the .shp sequentially). It is a pure function of the .shp, so it is fully regenerable: GDAL rebuilt IBGE's 316-byte .shx byte-identical to the original (case 2).
.dbf is the attribute table, in dBASE format; record n in the .dbf is feature n in the .shp. The specification calls it mandatory, but GDAL and the browser both open a layer without it, silently, with zero fields. It is not regenerable: the attributes live nowhere else.
.prj is a one-line text file with the coordinate reference system in WKT. Optional in the specification, mandatory in practice: without it GDAL reports Layer SRS WKT: as (unknown) and nothing knows whether the numbers are degrees or metres. Regenerable only if you know the CRS (ogr2ogr -a_srs), the subject of the first post in this series.
.cpg is a one-line file naming the .dbf encoding (IBGE's says UTF-8, five bytes). Optional; regenerable if you know the encoding (echo UTF-8 > BR_UF_2022.cpg). The second post in this series is about what goes wrong without it.
.sbn and .sbx (ESRI's spatial index, written by ArcGIS and never by GDAL), .qix (the open spatial index from GDAL, QGIS and MapServer) and .shp.xml (ArcGIS metadata) are optional, regenerable or disposable, and none of them is read by the browser viewer.
What you see for each missing file
The complete set (case 1)
Zip and loose files give the same row in the viewer: 27 polygons and 5 fields, CRS GCS_SIRGAS_2000 under Details, exported GeoJSON starting at [-68.7928173712301, -10.999569659337354]. GDAL: Feature Count: 27, GEOGCRS["SIRGAS 2000", five fields. Every case below is this set minus one file; "opens" means the row and the export are identical to this one.
No .shx (case 2)
In the viewer, nothing changes. Zip or loose, the row and the export are identical to the complete set. The parser never opens the .shx, and the loose-file path does not even look for one, so the browser is a quick way to confirm the .shp itself is healthy.
GDAL refuses, and says why: ERROR 4: Unable to open cases/2-no-shx/BR_UF_2022.shx or cases/2-no-shx/BR_UF_2022.SHX. Set SHAPE_RESTORE_SHX config option to YES to restore or create it. The fix is the one it names: ogrinfo -so BR_UF_2022.shp BR_UF_2022 --config SHAPE_RESTORE_SHX YES opens the layer (27 records, five fields) and a 316-byte BR_UF_2022.shx appears next to the .shp. Compared with IBGE's original using cmp: byte-identical. SHAPE_RESTORE_SHX is a --config option, not a driver open option. The "Errors, decoded" section of the Shapefile guide quotes the same line.
No .dbf (case 3)
The viewer opens it and says nothing. The row reads 27 polygons and 0 fields, the CRS is shown, there is no banner, and the export is the same geometry with "properties": null on every feature; zip and loose behave identically. The tool's own description admits it: "A standalone .shp shows geometry without attributes."
GDAL opens it and says nothing either. ogrinfo -so prints Feature Count: 27 and the CRS with no field lines and no DBF_DATE_LAST_UPDATE metadata; -fid 0 prints the polygon with no attributes. There is no fix: the .dbf cannot be rebuilt from the geometry, so ask whoever exported the layer for the whole set.
No .shp (case 4)
The viewer stops with a banner: No .shp file found. Drop a .shp file or a ZIP containing one. The same string appears whether the remaining files come as a zip or as loose files.
GDAL cannot open a layer (ogrinfo BR_UF_2022.shp ends in No such file or directory), but it opens the orphaned .dbf as a table: ogrinfo BR_UF_2022.dbf reports Geometry: None, Feature Count: 27, Layer SRS WKT: (unknown) and the five fields, and -fid 0 prints NM_UF (String) = Acre. The attributes survive a lost .shp; the geometry does not.
No .prj (case 5)
A missing .prj is a different failure, the layer opens and nothing knows what its coordinates mean, and it has its own post: Shapefile in the wrong place: the missing .prj.
Missing or wrong .cpg (case 6)
A missing or wrong .cpg stops nothing from opening; it turns accents into é, and that is the second post: Shapefile with wrong accents: .cpg, Latin-1 and UTF-8.
The macOS zip (case 7)
A zip made in Finder carries a __MACOSX/ folder with a ._BR_UF_2022.shp metadata stub for each file (Finder's resource-fork data, not a copy of the file). The viewer skips every __MACOSX entry, so a zip whose only .shp is that stub gets the same banner as case 4: No .shp file found. Drop a .shp file or a ZIP containing one. With the real files beside the folder (the usual Finder zip) it opens exactly like the complete set. GDAL agrees: the stubs-only zip is not recognized as being in a supported file format; the full one lists BR_UF_2022 (Polygon) through /vsizip/.
When the banner is lying (case 8)
One honesty note: for a zip, the viewer reports any failure inside its parser as "No .shp file found", including a .prj the parser cannot read and a shape type it does not know. If you are sure the .shp is there, suspect the .prj first. GDAL, for its part, opens the same files and prints no warning at all: it silently treats an unreadable .prj as an absent one and reports Layer SRS WKT: as (unknown); only gdalsrsinfo BR_UF_2022.prj names the problem (ERROR 1: missing [).
Test files you can use
The dataset: 13,717,460 bytes, SHA-256 282ec7f0f0beeeead45e6609f4ffffce161bda04cb8ee0afcad2316d1c841bcb, SIRGAS 2000 (EPSG:4674). The directory listing prints no licence line; credit IBGE and check the portal's terms.
To make any case above, unzip it, delete one file, and drop the rest into the viewer (or re-zip them with zip -j so no folder is added):
unzip -o BR_UF_2022.zip(five files:.cpg,.dbf,.prj,.shp,.shx).rm BR_UF_2022.shxfor case 2,rm BR_UF_2022.dbffor case 3,rm BR_UF_2022.shpfor case 4.
If the attributes open but the column names look cut short, that is not a missing file but the format's 10-character limit, the third post in this series: Shapefile column names truncated to 10 characters.
For teams
Finding the missing file is the easy half. Someone sent you a Shapefile because a team has to do something with those polygons: a status per feature, photos and a form from the field, a report by Friday. Geodocs imports the same set onto a team map, keeps the .dbf columns as fields the team fills in, runs the review and produces the report with the map in it. The viewer is where you check the file; the workspace is where it becomes work.