The Shapefile Is Dead. Here's What to Use Instead

The Shapefile format turns 33 this year. It was designed by ESRI in 1993 for ArcView GIS, a Windows 3.1 application. Fax machines were cutting-edge. The internet was a university experiment.

And yet, in 2026, Shapefile is still the most commonly requested format in government procurement documents, contractor deliverables, and GIS job postings. It works, it's everywhere, and everyone's tools support it. That's the good news.

The bad news is that working with Shapefiles in any modern workflow involves a constant low-level friction that adds up. If you've ever lost a column name, hit an invisible file size wall, or sent a ZIP file and had to explain what the other person should do with it, you've already felt the problem.

Here's an honest look at what's broken, what to use instead, and when Shapefile is still the right call.

What's actually wrong with Shapefile

It's not one file, it's a bundle. A Shapefile is at minimum three separate files: .shp (the geometry), .dbf (the attribute table), and .shx (an index). There's usually a .prj file for the coordinate system, and sometimes a .cpg file for character encoding, and a .qpj, and others. They all need to share the same base name and travel together.

Lose the .prj and your data has no defined coordinate system. It might still display, but anyone opening it has to guess which projection it's in. For the uninitiated: a coordinate system tells software how to interpret the numbers in the file. Without it, "correct" and "slightly off" look identical until something breaks downstream.

Email attachments, file transfers, and human error have eaten countless .prj files. The only safe way to send a Shapefile is as a ZIP archive, which means the recipient has to unzip it and know which file to open. For non-GIS people, this is a hard stop.

The 2 GB file size cap. The .dbf and .shp components each max out at 2 GB. For many datasets this is fine. For detailed parcel data covering a large city, high-resolution coastlines, or national-scale point datasets, it's a real constraint. You end up splitting data across multiple files, which creates its own management problems.

10-character column names. The .dbf format, which stores all the attribute data, is based on dBASE III from 1983. It limits column names to 10 characters. "Parcel ID" becomes "PARCEL_ID" at best, "PARCE" or "PARCELID_1" at worst, depending on what software exported it. If you have a column called "Last Inspection Date" and another called "Last Inspection Time," one or both are getting truncated in ways that may not be obvious until something breaks.

One geometry type per file. A Shapefile can hold points, lines, or polygons, but not a mix. If your dataset has buildings (polygons), access roads (lines), and entrance points (points), you need three separate Shapefiles. Managing three files where one logical dataset lives is friction that adds up on large projects.

No nested data. Shapefiles have a flat table structure. Each entry gets one row, and each column holds a single value. If you need to store multiple measurements per entry, multiple photos per parcel, or any kind of list, you have to work around the format. Usually that means multiple columns with names like photo_1, photo_2, photo_3, which is fine until there's a photo_4.

What to use instead

GeoJSON for web work and APIs. GeoJSON is a plain text format based on JSON, which is the language the web uses to pass data between systems. It's a single file. It handles mixed geometry types. Column names can be as long as you want. It's human-readable in a text editor. Any modern web mapping library, API, or cloud service reads it natively.

If you're building anything web-facing, sending data to a developer, or working with a tool that has an API, GeoJSON is the right default. The GeoJSON vs Shapefile comparison goes deeper on the tradeoffs if you're weighing formats for a specific project.

One honest caveat: GeoJSON files can get large because they're text. A dataset that's 200 MB as a Shapefile might be 500 MB as GeoJSON. For very large datasets this matters. For most working files it doesn't.

GeoPackage for desktop GIS work. GeoPackage is a single .gpkg file based on SQLite. It has no file size limit, supports mixed geometry types, allows long column names, and can hold multiple layers in one file. QGIS, ArcGIS, and most other GIS tools support it.

If you're doing a lot of desktop GIS work and tired of managing Shapefile bundles, GeoPackage is the cleaner replacement. One file, everything in it, no companion files to lose.

KML and KMZ for sharing with non-GIS people. KML is Google's format, designed for Google Earth. If you're sending map data to someone who doesn't have GIS software, KMZ (the compressed version) opens directly in Google Earth, which is free and requires no installation beyond a browser.

This isn't a format for serious data work. The attribute handling is limited and the geometry capabilities are narrower than GeoJSON or GeoPackage. But for getting a map in front of a client, a colleague, or anyone who just needs to see where things are, it's hard to beat.

See what is a Shapefile for more context on the format's history if you're newer to geodata and want the full picture.

When Shapefile is still the right choice

This is worth being honest about: Shapefile is still the right format in a specific and very common situation.

When you're delivering data to a government agency, a municipality, or a contractor with a legacy system, there's a real chance their system only accepts Shapefiles. Procurement specs written five or ten years ago often mandate it. Some cadastral systems, planning portals, and regulatory submissions have Shapefile as the only accepted input.

In those cases, you use Shapefile. Not because it's better, but because it's what the receiving end accepts. Format choice isn't always about what's technically correct. Sometimes it's about what clears the door.

The practical workflow for most people in 2026 is: work in GeoJSON or GeoPackage internally, convert to Shapefile when a specific recipient requires it. You get the better format for your day-to-day work and can still deliver what's needed for legacy systems.

Converting between formats

Georaf.com converts Shapefiles to GeoJSON and back in one step. Upload a ZIP containing your Shapefile bundle, choose the output format, and download. No software installation, no command line, no Python scripts.

If you're working with KML or KMZ as well, Georaf handles those too. The format conversion page covers all supported directions.

The broader point is that being locked into Shapefile is no longer a technical constraint. The conversion tools exist. The question is just whether the receiving end requires it.

Shapefile isn't going away anytime soon. Too much infrastructure depends on it. But "it's everywhere" is not the same as "it's good," and for your own working files, you have better options today.