GeoJSON to GeoParquet Converter

Why convert GeoJSON to GeoParquet

GeoJSON is easy to read and easy to write by hand, which is exactly why it became the default format for sharing map data on the web. But that same simplicity is a cost once a dataset grows past a few thousand features. GeoJSON stores every coordinate as plain text inside a JSON structure, and a reader has to parse the entire file, brace by brace, before it can look at even one property. There is no way to read only the columns you need, and there is no way to know a file's extent without opening and scanning the whole thing.

GeoParquet solves this by borrowing the column-based storage that data engineers already use for large tabular datasets. Each property becomes its own column, geometry becomes a binary column of WKB values, and the file carries a small metadata block that states the geometry types and the overall bounding box up front. A tool like DuckDB or GeoPandas can then read only the columns a query actually needs, skip files whose bounding box does not overlap an area of interest, and rely on Parquet's built-in compression to shrink repeated values like place names or status codes.

This tool exists to remove the friction from that first step. Instead of installing GDAL, a Python environment, or a command-line tool, you can drop a GeoJSON file in your browser and get back a working GeoParquet file within seconds. The conversion runs client-side using WebAssembly, so the tool works the same whether your file has ten features or a hundred thousand, and your data is never sent anywhere.

GeoParquet: history, structure, and facts

GeoParquet is built on top of Apache Parquet, a column-oriented file format that Twitter and Cloudera released as an open-source project in 2013 for large-scale data processing on Hadoop. Parquet itself has no idea what a coordinate is; it just stores typed columns efficiently, with per-column compression and metadata that lets a reader skip whole blocks of data it does not need.

The GeoParquet specification adds geospatial rules on top of that general-purpose format. It was developed by an open community working under the Cloud-Native Geospatial Forum, with the first 1.0.0 release published in August 2023. Version 1.1.0, released in 2024, added optional support for a per-row bounding-box column and a "covering" field, both aimed at letting a reader filter rows without decoding every geometry.

A few facts worth knowing: GeoParquet stores geometry as WKB by default, so any language with a WKB library can read the geometry column even without GeoParquet-specific tooling. The specification assumes longitude/latitude order in OGC:CRS84 unless a file states another coordinate reference system using PROJJSON. And GeoParquet has already been adopted well beyond experiments: Overture Maps, the joint mapping project backed by Amazon, Meta, Microsoft, and TomTom, publishes its entire global dataset, buildings, places, roads, and administrative boundaries, as GeoParquet, and Source Cooperative hosts dozens of public GeoParquet datasets for anyone to query directly from cloud storage.

In short, GeoParquet is not a new geometry model. It is an agreement on how to place existing, well-understood geometry encoding inside a fast, columnar file format that the rest of the data engineering world already relies on.

Step-by-step guide

Step 1

Choose a .geojson file from your computer, paste GeoJSON text directly into the box, or click "Try sample" to load a small ready-made file of German cities.

Step 2

Once your GeoJSON is loaded, click "Convert to GeoParquet". The conversion runs entirely in your browser and finishes in a fraction of a second for typical files.

Step 3

A summary appears: how many features were converted, which geometry types were found, the bounding box, the property columns, and the resulting file size.

Step 4

The source features are drawn on the map so you can confirm the right data was converted before downloading anything.

Step 5

Click "Download converted.parquet" to save the finished GeoParquet file to your computer.

Six real-world use cases

Where GeoParquet actually gets used, beyond the file format itself.

1. Publishing large open datasets. Projects like Overture Maps publish global building and place datasets as GeoParquet because a single file can hold millions of features while staying fast to query by region.
2. Loading geospatial data into a cloud data warehouse. BigQuery, Snowflake, and DuckDB all read Parquet natively. Converting GeoJSON to GeoParquet first means the geometry column loads alongside the rest of the table with no separate import step.
3. Feeding machine learning pipelines. Training pipelines that read many small files benefit from Parquet's columnar layout: a model that only needs coordinates and one label column can skip every other property instead of parsing a full GeoJSON object per row.
4. Archiving municipal and government GIS datasets. Open-data portals that currently ship city boundaries, zoning, or parcel data as GeoJSON can offer a GeoParquet copy alongside it, giving analysts a smaller, faster-to-query file for the exact same data.
5. Cataloging satellite and remote-sensing footprints. Scenes and tile footprints from satellite imagery are naturally tabular: one geometry plus metadata like capture date and cloud cover per row, which is exactly the shape a columnar format like Parquet is built for.
6. Pre-processing data for a web mapping pipeline. Data engineers building vector tiles or map backends often stage raw GeoJSON as GeoParquet first, since downstream tools like DuckDB spatial or Apache Sedona can filter and reshape millions of features far faster than re-parsing JSON text.

Technical questions and answers

Ten common questions about how this converter works, answered directly.

The mathematics behind the conversion

The conversion has no ambiguity or estimation in it. Every step is a fixed, reversible operation on bytes and numbers, which is what makes a byte-for-byte round trip possible. Here is what actually happens to your data.

1. Coordinates are already IEEE-754 doubles

A GeoJSON coordinate like 13.404954 is parsed by JavaScript's JSON parser into a 64-bit IEEE-754 double-precision float: 1 sign bit, 11 exponent bits, and 52 mantissa bits, giving roughly 15 to 17 significant decimal digits of precision. WKB stores each coordinate as exactly this same 8-byte double, written out in little-endian byte order. No rounding or format change happens here; the conversion copies the same 64 bits that were already in memory into the output buffer.

2. WKB byte layout and size

Every WKB value starts with a 1-byte endianness flag and a 4-byte unsigned integer geometry-type code, so the fixed header is always 5 bytes. After that, the size depends on the geometry type. For a ring of n coordinate pairs (used by LineString and each ring of a Polygon), 4 bytes record the point count and then each pair costs 16 bytes (8 for X, 8 for Y):

ring_bytes(n) = 4 + 16n

Point           = 5 + 16                                  = 21 bytes
LineString(n)   = 5 + ring_bytes(n)
Polygon(rings)  = 5 + 4 + Σ ring_bytes(ring)   for each ring
MultiPoint(n)   = 5 + 4 + 21n                  (each point repeats the 5-byte header)
MultiLineString = 5 + 4 + Σ (5 + ring_bytes(line))   for each line
MultiPolygon    = 5 + 4 + Σ (5 + 4 + Σ ring_bytes(ring))   for each polygon, each ring

This is precise, not approximate: the converter computes the exact byte size for a geometry before allocating its buffer, writes the header and every coordinate with a DataView, and never resizes the buffer mid-write. A simple two-point line therefore takes exactly 5 + 4 + 32 = 41 bytes, every time, on every platform.

3. The bounding box is a single linear pass

The bounding box [minX, minY, maxX, maxY] is computed by visiting every coordinate pair exactly once and keeping a running minimum and maximum, an O(n) reduction where n is the total number of coordinate pairs across all features. There is no sorting and no second pass: each new coordinate only ever needs to be compared against the four running values, so the cost of computing the bbox grows linearly with the size of the dataset, never faster or slower.

4. Why the file ends up smaller

A GeoJSON coordinate pair like [13.404954, 52.520008] takes around 20 bytes as text, including brackets and the comma. The same pair as two WKB doubles takes exactly 16 bytes, a modest saving on its own. The larger gain comes from Parquet's column-level encoding: a text property column such as a country name repeated across thousands of rows compresses extremely well under dictionary encoding, since Parquet only has to store each distinct string once plus a short integer reference per row. Numeric columns benefit similarly from run-length and bit-packing encodings when values repeat or fall in a narrow range. None of this is available to a row-based text format like GeoJSON, where every value is re-written as text on every single row.

Put together, the conversion pipeline is deterministic at every stage: parse a known IEEE-754 double, write it into a known byte layout, track a running min/max, and hand the result to a general-purpose columnar compressor. That determinism is exactly what makes the round trip lossless, and it is why the same GeoJSON file converted twice on two different machines produces byte-identical GeoParquet output.