Shapefile Won't Open? The Missing .shx and .dbf Problem, Fixed

You double-click a Shapefile and nothing opens. Or it opens and the map is blank. Or a tool says the file is corrupt. Nine times out of ten, the file is not corrupt at all. A part of the set is missing. A Shapefile is a team of files, and a team with a player missing cannot play.

This guide shows you how to spot which part is gone, what each part does, how to get it back, and what you can still save when a part is gone for good. You will upload the parts together and let the tool group them as part of the fix, so you can see at once what the tool can read.

Work through the checks in order. They go from the most common cause to the least, and each one takes a minute or less. Do not reinstall your GIS program. Do not pay for a repair tool. Start with the file list.

The Parts of a Shapefile, One by One

The .shp part holds the shapes themselves: the points, lines, and polygons, stored as packed numbers. It is the part people mean when they say 'the Shapefile', and the part they send alone by email — which is where the trouble starts. On its own, it is a body with no index and no facts.

The .shx part is the index. It is a short list that says where each shape starts in the .shp part, so a program can jump to shape 4,000 without reading shapes 1 to 3,999. It is small — much smaller than the .shp — and easy to lose when files are copied by hand, since it looks like a spare part. It is not spare. Most programs refuse to open the set without it.

The .dbf part is the table: one row per shape, with the facts — names, codes, areas, dates. Without it, programs may show shapes with no facts, fail to open, or open with an empty table that looks like data loss. Two more parts round out the set: .prj names the coordinate system, and .cpg names the text code for the table. A set can open without those two, but the map may sit in the wrong place, or names may show strange marks.

Why Parts Go Missing

Email is the top cause. A sender attaches the one file they see, roads.shp, and sends it. The other three parts sit in their folder, unsent. File shares are the second cause: a sync tool skips small files it judges as temp files, or a copy is cut off mid-way and the small parts, copied last, never land.

Renames are the third cause. A well-meant rename of roads.shp to roads-2026.shp breaks the set unless every part gets the same new name. The parts find each other by name. One part with a different name is, to the program, a missing part. Case counts too on strict systems: Roads.shp and roads.dbf can fail to pair.

The fix, in most cases, is not repair. It is reunion. Get the parts back in one folder, with one shared name, and the file opens as if nothing was wrong. The steps below start there. Only when a part is truly gone do you move to the salvage steps — and even then, more can be saved than most people fear. Once fixed, store the fixed data as one GeoPackage file and the problem can never recur: a GeoPackage has no parts to lose.

Words to Know

The ZIP term matters most here. A ZIP is how a set of parts should always travel.

• Feature. one real thing on the map, such as one park, one road, or one shop. A file can hold many features.
• Attribute. a fact about a feature, stored as text or a number. A park has a name. A road has a speed limit. Those facts are attributes.
• ZIP file. one packed file that holds many files in it. A Shapefile needs a ZIP, since a Shapefile is three or more files that must travel as one set.
• Coordinate system (CRS). the rule that says what the numbers in a file mean. It tells a program where each point sits on Earth. Without it, numbers are just numbers.
• Layer. one set of features of one kind, shown as one sheet on a map. A city file may hold a roads layer and a parks layer.

First, Rule Out the Simple Causes

Before you touch the data, run these three fast checks. Most 'corrupt' Shapefiles are cured by one of them:

• List the folder. Do you see at least .shp, .shx, and .dbf with the same base name?
• Check the names letter for letter, case too. One part with a different name is a missing part.
• Check the sizes. A .shp of 0 KB, or a .dbf far smaller than its row count needs, points to a cut-off copy.

If all three checks pass and the file still will not open, the fault is deeper — a damaged .shp or a table written by a loose tool. Even then, upload the set here and read the error. The tool names the part and the fault it found, which beats a bare 'corrupt file' message. And if the set opens but sits in the wrong place, set the coordinate system by hand when the .prj is gone using the steps in our reprojection guide.

What Each Symptom Means

Match your symptom to a row. The table is the whole diagnosis in one view:

Two rows deserve a note. The .shx row is the kind one: an index can be rebuilt from the .shp part alone, since it is just a list of where each shape starts. Many GIS tools rebuild it on save, and our converter reports the missing index and, where the shapes are sound, can still read the set for conversion. The .dbf row is the stern one: if the table part is gone and no copy exists, the facts are gone. The shapes can still be converted and mapped, but names and codes must come from another source.

Keep that table in mind when you ask for a re-send. Ask for the whole set as one ZIP, never as loose parts. One ZIP, one click, no parts left behind. It is the single habit that ends this class of problem for a whole team.

Keep Your Source Safe

Work on a copy, not on your only file. Save the first file in a safe place and do not change it. If a test goes wrong, you can start again from the clean source. This sounds like a small point, but it saves more work than any other habit in this guide.

Give each test a clear name. A name like test-1 tells you the order of your tries. A name like final-final-2 tells you nothing at all. When you find the settings that work, write them down in a short note next to the files. The next file of the same kind will then take minutes, not an hour.

How to Fix a Shapefile That Won't Open

Steps 1 to 3 reunite the set. Steps 4 and 5 handle a part that is truly gone. Step 6 proves the fix, and Step 7 stops it from happening again.

Step 1: List the parts and match the names

Open the folder and write down each part you have, with its full name. You need .shp, .shx, and .dbf at least. Every part must share one base name, letter for letter. Fix any rename drift now: if roads-2026.shp sits next to roads.shx, rename all parts to one shared name. Keep a note of the names as sent, in case you must report the fault to the sender.

Step 2: Ask for a re-send as one ZIP, if a part is absent

If a core part is not in the folder at all, stop and ask. Tell the sender the exact part names you need, and ask them to ZIP the whole set and send the ZIP. This takes them two minutes and fixes the problem in full, with no salvage work. Most senders do not know a Shapefile is a set. Your note teaches them, kindly, and saves the next person too.

Step 3: Upload the reunited set and read the summary

ZIP the parts and drop the ZIP on the home page. The summary should name the layer, the shape type, the feature count, and the coordinate system if a .prj is present. If the tool still reports a missing part, compare its list to yours: the name it wants is the name to check. A part in a subfolder inside the ZIP is a common miss — parts belong at the top level of the ZIP.

Step 4: If the .shx is gone for good, rebuild the index

Open the set in QGIS if you have it: QGIS can read a .shp with no .shx in some cases and will write a fresh index when you save or export the layer. Or convert the set here: upload the .shp and .dbf and read the report. If the shapes are sound, export a fresh Shapefile ZIP or a GeoJSON. The export writes a clean, complete set with a new index built in.

Step 5: If the .dbf is gone for good, save the shapes and rebuild the facts

Convert the shapes to GeoJSON or GeoPackage at once, while they still read. You now have the geometry safe in a modern file. Then rebuild the facts from whatever source holds them: the sender's spreadsheet, the web page the data came from, or a join on a code stored in a second file. Do not hand-type a large table. Find a source with the facts in rows, and join on a shared key.

Step 6: Prove the fix with counts and a map check

Whatever road you took, end with the same proof: feature counts match the sender's count or the count in a related file; fields are present with names you expect; the preview puts the data in the right place. If the .prj was part of the problem, the place check is the proof that matters most. A file that opens in the wrong ocean is not fixed.

Step 7: Repack the fixed set so it stays fixed

Export or save the repaired data as one ZIP if it must stay a Shapefile, or as a GeoPackage if it can move on. Name it with the date. Send that file — and only that file — when you share the data on. Then convert the repaired set to GeoJSON as well if a web map needs it, while the set is whole and checked.

How to Check Your Result

Never trust a conversion you have not checked. The good news is that a sound check takes just a few minutes, and it is the same each time you work on a Shapefile repair.

First, match the counts. The report shows how many features went in and how many came out. The two counts should be the same. If the output count is lower, a step dropped data, and you should find out why before you share the file.

Next, look at the map preview. Your data should sit in the right town, state, or sea. If it sits in the ocean, or on the wrong side of the world, the coordinate system is the prime suspect. Zoom in on one place you know well and check that roads, parks, or points fall where they should.

Then check the fields. Open the field list in the report and read the names. Make sure the key fields are still there, with the right names and the right kind of values. Pick one feature you know and match each value back to the source by hand.

• Open the fixed file in a second tool if you can. A set that opens in two tools is a set you can trust.
• Count rows in the table and shapes on the map. The two counts must match; a gap means a part is still out of step.
• Check three names with marks or long words. Text faults hide in the table long after the shapes look fine.

Last, keep the source file. Save the result with a clear name that holds the date and the format, like parks-geojson-2026-11-07.zip. Keep the source and the result in one folder. If a question comes up next month, you can trace each feature back to where it came from.

Common Mistakes and How to Fix Them

It Opens on My Machine but Not on Theirs

One of you has an extra part the other lacks. The classic case: your folder holds a .shx that was never sent. Compare full folder lists, not file names. Send the whole set as one ZIP and the gap closes.

The ZIP Upload Says a Part Is Missing, but It Is in the ZIP

Check for a folder inside the ZIP. If the parts sit in a subfolder, some tools look only at the top level. Unpack, re-ZIP the parts at the top level with no folder, and upload again. Also check for a doubled name like roads.shp.shp from a rename on a machine that hides extensions.

Shapes Open but Every Fact Is Blank

The .dbf is there but empty or from a different set — same name, wrong file. File sizes are the tell: a table for 5,000 rows is not 1 KB. Get the right .dbf from the sender, matched by the date and size of the other parts.

The Repair Worked, Then Broke Again Next Week

The set is being stored loose in a synced folder that drops small parts, or shared by email one part at a time. Change the storage, not the data: keep and send the set as one ZIP, or move the working copy to GeoPackage, which is one file by design.

A Tool Says the .shp Itself Is Damaged

This is the rare real corruption. Try a copy from a backup or a fresh download first — most 'damage' is a cut-off copy. If the only copy is truly damaged, salvage what reads: convert the set and note the feature count you recover. Report the gap to the sender with the counts, so they know what was lost and can re-send from their master.

What the Plans Allow

You can start free. The Free plan gives you 5 conversions a month, with one file at a time and a size limit of 25 MB per file. That is enough to test a rescued Shapefile set on real data and check the result with care.

Starter costs $9 a month. It gives you 200 conversions a month, files up to 500 MB, and batch jobs of up to 10 files at once. Pro costs $19 a month. It gives you 1,000 conversions a month, files up to 5 GB, batch jobs of up to 25 files, and API access for work you run on a schedule. You can check plans if rescues are a weekly job before you pick.

All plans work the same way at the core. You get a map preview, feature counts in and out, and a clear report if a file has a fault. Your files are kept for 72 hours so you can download them again, and then they are deleted.

Frequently Asked Questions

Can I open a Shapefile with only the .shp part?

Not in most tools, and not with its facts. The .shp holds shapes alone. Some tools will limp open the shapes if you rebuild the index, but the table needs the .dbf. Always hunt down the full set first. Reunion beats repair, every time.

Is the .shx really required? It is so small.

Yes. Its size fools people. It is the index that lets a program find each shape. Without it, strict programs refuse the set. The good news: it is the one core part that can be rebuilt from the .shp alone, since it holds no unique data — just positions.

My .prj is missing. Is the file broken?

No. The data is whole; only the label of its coordinate system is gone. If you know the system, assign its EPSG code when you convert or open the file. If you do not know it, ask the sender. Guessing can put the data in the wrong place while looking fine at a glance.

Why do people keep sending me just the .shp?

Because it looks like the file. The other parts look like clutter, and many senders have never been told the set works as one. A kind, short note back — asking for the whole set as one ZIP, and naming the parts — fixes it for you and for everyone they send to next.

How do I stop this problem for good?

Two habits. Send and store Shapefiles only as ZIPs. And keep working data in a single-file format — GeoPackage for GIS work, GeoJSON for the web — making Shapefiles only as exports for tools that demand them. No parts, no problem.

Final Checklist

Run through this short list before you share your file:

• .shp, .shx, and .dbf are present with one shared base name.
• Feature count and table row count match.
• The preview puts the data in the right place, or the EPSG was assigned by hand.
• Names and text read clean, with no strange marks.
• The fixed data is saved as one ZIP or as a GeoPackage, with the date in the name.

If each point passes, your file is ready to use.

References

• https://gdal.org/en/stable/drivers/vector/shapefile.html — The GDAL Shapefile driver notes. They describe the parts of a set and how a directory of Shapefiles is treated as a dataset.
• https://www.loc.gov/preservation/digital/formats/fdd/fdd000280.shtml — The Library of Congress format note for the ESRI Shapefile, listing the mandatory and optional component files.
• https://www.census.gov/geographies/mapping-files/time-series/geo/tiger-line-file.html — The Census Bureau TIGER/Line Shapefiles page, a working example of Shapefiles distributed as complete sets.