Every GIS user eventually faces the same question: which file format should this data live in? The three formats you will meet most often are Shapefile, GeoJSON, and GeoPackage, and each was designed for a different era and a different job. Shapefile dates from the early nineteen-nineties and remains everywhere out of habit, GeoJSON is the lightweight format of web mapping, and GeoPackage is the modern, standards-based container designed to replace Shapefile. Knowing their trade-offs saves you from corrupted data, lost attributes, and compatibility headaches.

A Shapefile is not one file but a set of at least three, with .shp holding geometry, .shx holding an index, and .dbf holding attributes, plus optional files for projection and spatial indexing. That multi-file structure is the source of its most famous failure: email someone only the .shp and they receive geometry with no attributes and no coordinate system, a useless dataset that looks intact. Field names are limited to ten characters, attribute types are limited, file sizes are capped around two gigabytes, and there is no support for modern features like curved geometries or multiple layers in one file.

Despite all that, Shapefile survives because almost every GIS tool reads it, archives are full of it, and many government datasets are still published in it. If you receive data as a Shapefile, QGIS will handle it fine, and there is no need to convert on principle. But for new work, especially work you will share, its limits are real, and its quirks, like the ten-character field names silently truncating your carefully chosen column names, will eventually bite. Treat Shapefile as a legacy format to read, not a default format to write.

GeoJSON stores geographic features as plain text in JSON format, which means any programmer can read it, any web map can load it, and you can open it in a text editor and understand what you are looking at. That readability makes it ideal for web applications, APIs, and small datasets, and it is the format most web mapping libraries expect. Its weaknesses are size and precision: text is verbose, so large datasets become slow and bulky, and it has no built-in spatial indexing, so a million-feature GeoJSON will strain a browser that a database format would handle easily.

GeoJSON also carries no formal coordinate system by specification, it assumes longitude and latitude, which is fine for web maps but a trap if your data are projected. Attribute types are limited to what JSON supports, and there is no standard way to store styling or multiple geometry types cleanly in one file. Use GeoJSON when the audience is the web, the dataset is modest, and readability matters; avoid it as an archive format for large or complex data, where a binary format will be faster, smaller, and safer.

GeoPackage is an open standard based on SQLite, a single self-contained file that can hold multiple vector layers, raster tiles, and rich attribute types, with no practical size limit and full support for long field names. It is the default format QGIS suggests for new layers, it carries its coordinate system inside the file, and a single .gpkg file emailed to a colleague arrives complete, unlike a Shapefile's scattered parts. It also supports spatial indexing, so large datasets stay responsive, and its database foundation means it plays well with tools beyond traditional GIS.

The case for GeoPackage as a default is strong: for most desktop GIS work, it is simply the better Shapefile, with fewer limits and fewer surprises. Its main drawback is youth, in that some older or highly specialised tools may not support it, and web applications still prefer GeoJSON for direct loading. A practical rule, then, is to work and archive in GeoPackage, publish to the web in GeoJSON, and read Shapefiles whenever they arrive without converting them unnecessarily. That division keeps each format doing the job it was designed for, and keeps your data safe in the process.