You run a GeoJSON-to-Shapefile conversion. The tool says it succeeded. You load the Shapefile into ArcGIS or QGIS and everything looks fine at first glance. Three weeks later, someone discovers that half the attribute data is wrong or missing.

This is not hypothetical. It happens constantly in GIS workflows, and the reason is that GeoJSON and Shapefile are fundamentally different formats with incompatible assumptions about how data should be stored. Most conversion tools handle the geometry correctly but silently destroy the attributes.

The 10-Character Field Name Problem

This is the single most common source of data loss in GeoJSON-to-Shapefile conversion, and most people don’t even know it exists.

GeoJSON properties can have field names of any length. You might have fields like population_density_2024, land_use_classification, or environmental_impact_score. These are perfectly valid GeoJSON property names.

Shapefile’s DBF format has a hard limit of 10 characters per field name. When a conversion tool encounters population_density_2024, it has to truncate it. Different tools handle this differently:

  • GDAL/ogr2ogr truncates to 10 characters and appends a number if there are collisions: populati_1, populati_2
  • Some web tools silently drop fields that exceed the limit
  • Others truncate without collision detection, meaning population_density and population_estimate both become population, and one overwrites the other

The result is that your converted Shapefile has field names that don’t match your source data, and if you have multiple long field names with similar prefixes, you may lose entire columns of data.

The 254-Character Value Limit

Shapefile’s DBF format also limits text field values to 254 characters. GeoJSON has no such limit. If your GeoJSON features have a description field with detailed text, or a metadata field with JSON-encoded values, anything beyond 254 characters gets silently chopped.

This is particularly nasty because the truncation happens at the byte level, not the character level. If your text contains UTF-8 encoded characters (accented characters, CJK characters, emoji), the truncation point may land in the middle of a multi-byte character sequence, producing garbled text at the end of the field.

Geometry Type Mismatches

GeoJSON supports mixed geometry collections — a single FeatureCollection can contain Points, LineStrings, and Polygons side by side. Shapefile requires all features to be the same geometry type.

When you convert a mixed-geometry GeoJSON to Shapefile, the conversion tool has to make a choice:

  • Split into multiple Shapefiles — one per geometry type (this is the correct approach)
  • Promote everything to the most complex type — convert Points to single-vertex Polygons (this is technically valid but semantically wrong)
  • Drop non-matching features — silently remove any features that don’t match the dominant geometry type

If you’re not watching carefully, the third option is what many quick conversion tools do. Your source GeoJSON has 1,000 features, your output Shapefile has 847, and nobody notices until the data is used in an analysis.

CRS and Projection Traps

RFC 7946 specifies that GeoJSON coordinates must be in WGS84 (EPSG:4326). In practice, plenty of GeoJSON files use other coordinate reference systems without declaring them, or declare a CRS using the deprecated crs member that most parsers ignore.

Shapefile handles CRS through a separate .prj file using OGC WKT format. If the conversion tool doesn’t correctly map the CRS from the GeoJSON source to the .prj file, your Shapefile loads in the wrong location. Everything looks fine within the Shapefile itself, but overlaying it with other data produces a mess.

The worst case is when the source GeoJSON has coordinates in a projected CRS (like UTM) but no CRS declaration, and the conversion tool assumes WGS84. The Shapefile generates with a WGS84 .prj file, but the coordinates are actually in meters, not degrees. The features render somewhere in the middle of the ocean near the equator.

Multi-Polygon Holes and Winding Order

GeoJSON uses the right-hand rule for polygon winding order (exterior rings counter-clockwise, holes clockwise), as specified in RFC 7946. Shapefile uses the opposite convention — exterior rings clockwise, holes counter-clockwise.

A proper conversion tool reverses the winding order during conversion. A lazy one doesn’t. When the winding order is wrong, holes in polygons may be interpreted as separate filled polygons, or exterior boundaries may be interpreted as holes. A donut-shaped polygon becomes either a solid disc or an invisible void.

This issue is particularly hard to catch because many GIS applications are forgiving about winding order and will render the polygon correctly regardless. The problem surfaces when you use the Shapefile in a stricter application, or when you perform area calculations and get negative values for features that should have positive area.

How GeoConvert Handles These Problems

GeoConvert was built specifically because these silent failures are unacceptable in professional workflows. Here’s how it handles each issue:

Field name truncation: GeoConvert warns you when field names will be truncated and shows the mapping. If truncation would cause collisions (two different source fields mapping to the same 10-character name), it flags the conflict and uses numbered suffixes. No silent data loss.

Value truncation: Text fields exceeding 254 characters are flagged in the conversion report. The truncation still happens (it has to — it’s a Shapefile limitation), but you know about it and can decide whether the data loss is acceptable.

Geometry validation: GeoConvert validates geometry before conversion. Self-intersecting polygons are detected and auto-repaired using GDAL’s geometry validation pipeline. Mixed geometry collections are split into separate outputs per geometry type.

CRS handling: The GDAL engine under the hood handles CRS detection and transformation correctly, including the RFC 7946 WGS84 assumption for GeoJSON files without explicit CRS declarations.

Winding order: Polygon winding order is automatically corrected during conversion to match Shapefile conventions.

What to Check After Any Conversion

Regardless of what tool you use, here’s a quick validation checklist:

  1. Feature count — does the output have the same number of features as the input?
  2. Field names — are all source fields represented? Are any truncated or missing?
  3. Sample values — spot-check a few features. Do the attribute values match the source?
  4. Geometry visual check — do polygons with holes still have holes? Do multi-part features still have all their parts?
  5. CRS overlay — load the output alongside known-good reference data. Do they align?

These checks take two minutes and can save you from discovering data corruption weeks after the conversion.

When Shapefile Isn’t the Right Choice

It’s also worth asking whether you actually need a Shapefile at all. The format dates from the 1990s and its limitations are well-documented. If your downstream tool supports GeoPackage, that format handles long field names, large text values, mixed geometry types, and proper CRS metadata without any of the problems described above.

But the reality is that many government agencies, utility companies, and legacy GIS systems still require Shapefile. When you have to convert, do it with a tool that tells you what it changed, not one that pretends everything went smoothly.

GeoConvert gives you two free conversions with no signup required at geoconvert.cadshift.com. After that, it’s pay-as-you-go based on file size — no subscriptions, no surprise bills.