How big is the same dataset in each format? To find out, I measured GIS file format sizes with a controlled experiment. One identical set of 10,000 survey points went through this site's conversion engine into seven other formats. Then every output was measured, re-opened and read back. The size gap was 16 to 1, and size was not the only difference.
First, the dataset. I generated 10,000 survey-style points spread across a realistic region, each with seven-decimal coordinates and six attribute columns: id, name, category, elevation_m, recorded_at and surveyor_note. The notes deliberately include accented text, so encoding survival gets tested too.
Next, the engine. Every conversion ran through GDAL 3.8.4 compiled to WebAssembly, which is exactly the engine behind the converters on this site. The flags match what the site passes, so these numbers describe what you actually download here. The dataset is generated from a fixed seed; as a result, anyone can reproduce the run byte for byte.
Finally, verification. Each output was re-opened with GDAL and read back. Therefore the table below reports not just size, but what survived the trip: fields, field names, dates and coordinates.
| Format | Size | Vs source | Attributes kept | Worth knowing |
|---|---|---|---|---|
| KML | 5,181,390 B | 1.9x | All 6, in ExtendedData | Largest by far; simple readers may surface only the name |
| Shapefile (5 files) | 3,180,576 B | 1.2x | All 6, names truncated | The .dbf alone is 89% of the total |
| GeoJSON (source) | 2,690,891 B | 1.0x | All 6 | The baseline the others were made from |
| GeoPackage | 1,994,752 B | 0.74x | 5 fields + id becomes the FID | Keeps full date-and-time values |
| CSV | 1,198,910 B | 0.45x | All 6, plus X and Y columns | Dates are reformatted |
| GPX | 728,185 B | 0.27x | Only the name | The GPX schema rejected the other 5 fields |
| Excel (.xlsx) | 583,041 B | 0.22x | All 6, plus X and Y columns | Numbers arrive typed as numbers |
| KMZ | 328,535 B | 0.12x | Same as KML | Just the KML, zipped; smallest of all |
So the spread in GIS file format sizes is enormous. The same points, the same attributes and the same precision take 5.2 MB as KML but 0.3 MB as KMZ. In other words, the container matters more than the content.
KML is XML, and XML repeats itself. Every one of the 10,000 placemarks carries its own opening tags, closing tags and field names. However, that repetition is exactly what compression loves. Zip the KML into a KMZ and it shrinks by 94%, which is why converting KML to KMZ before emailing is almost always worth it.
The shapefile surprised me from the other direction. Its geometry file (.shp) is only 280,100 bytes; lean, in fact. Instead, the bulk sits in the attribute table: the .dbf is 2,820,226 bytes, or 89% of the whole set. The dBASE format pads every text field to a fixed width with spaces, so short values still occupy their full column width. Consequently, wide text columns inflate a shapefile fast.
GeoPackage stores the same data in a binary SQLite database, which is why it lands 26% under the GeoJSON source while keeping everything queryable. Meanwhile, Excel looks small for a similar reason: a modern .xlsx is itself a zip archive of XML sheets. For a deeper comparison of the two container heavyweights, see GeoPackage vs shapefile.
One caution when you compare GIS file format sizes: GPX looks efficient here, but part of that is data loss. It kept one field out of six, so its 0.7 MB is not a fair fight.
GIS file format sizes are visible at a glance; the content changes are sneakier. These are the ones the read-back caught:
Precision worried me most, and it turned out to be a non-issue. The first point went in at longitude 62.8441543 and latitude 32.1100421. Every geographic format returned exactly those digits: KML, the shapefile, GeoPackage and GPX alike, and the CSV and Excel tables carried them as text columns unchanged. Seven decimal places is roughly a centimetre on the ground, and it survived every conversion. If your data lands in the wrong place after a conversion, precision is not the culprit; the coordinate system usually is.
Here is a 100-point cut of the exact benchmark dataset, in every format from the table. Drop one into any converter on this site and compare what comes out, or open them side by side in QGIS:
GeoJSON CSV KML GPX Excel GeoPackage Shapefile (zip)
Checking GIS file format sizes on your own data takes about a minute per format. And if you only remember three things: zip your KML, expect your shapefile's .dbf to dominate its size, and never send attributes on a round trip through GPX.
In this 10,000-point test, KMZ was smallest at 328,535 bytes, followed by Excel at 583,041 bytes. GPX was also small, but only because it dropped five of the six attribute fields on write.
The attribute table is the usual reason. The .dbf format pads every text field to a fixed width, and in this test the .dbf was 89% of the shapefile's 3.18 MB total. Wide text columns inflate it quickly.
Not in this benchmark. All seven decimal places, roughly centimetre level, came back identical from every format tested. Misplaced data after conversion almost always traces to a coordinate system problem, not to precision loss.
GeoPackage, GeoJSON, CSV and Excel all preserved every field and full field names. Shapefile keeps the values but truncates names to 10 characters and drops time of day from timestamps, while GPX keeps little beyond the waypoint name.
