GeoJSON to FlatGeobuf Converter
When you need a single-file binary alternative to Shapefile that doesn't truncate field names and ships with a built-in spatial index for fast random access.
Convert GeoJSON to FlatGeobuf now
Common issues converting GeoJSON to FlatGeobuf
- FlatGeobuf requires every feature to share a homogeneous schema — same property keys, same types. Heterogeneous GeoJSON inputs are normalised by taking the union of property keys; missing values become null.
- Geometry types within a single .fgb are also expected to be uniform (all Point, all LineString, etc.). Mixed-geometry GeoJSONs convert but some downstream readers refuse them; consider splitting first.
- The CRS is encoded in the FlatGeobuf header. We write WGS 84 by default — the rest of the conversion pipeline normalises everything to EPSG:4326 before write.
- Features without geometry are dropped (FlatGeobuf can't represent them).
Frequently asked questions
Why pick FlatGeobuf over Shapefile?
No 10-character field-name cap. No 2-GB file size limit. No multi-file bundle (everything is in one .fgb). Built-in spatial index for sub-millisecond random access. And it's a single binary file you can serve over HTTP range requests for partial reads.
Why pick FlatGeobuf over GeoParquet?
FlatGeobuf is row-oriented with a spatial index — better for "give me features intersecting this bbox" queries directly off object storage. GeoParquet is column-oriented — better for warehouse SQL aggregations across millions of rows.
Which tools read FlatGeobuf?
OGR/GDAL ≥ 3.1, QGIS ≥ 3.16, Carto, Felt, Mapbox Studio (via OGR), ArcGIS Online (Living Atlas), and dozens of JS libraries. The official `flatgeobuf` npm package is what we use under the hood.
What's the typical size compared to GeoJSON?
Roughly 30–60% smaller, plus a small overhead for the spatial index. Smaller than Shapefile in most cases too.