If you've spent any time working with geospatial data, you've probably had to deal with Shapefiles or KML files at some point. They get the job done, but they can also come with frustrations: Shapefiles scatter your data across half a dozen files. KML buries your attributes in untyped XML. Both formats start to strain as datasets grow larger. GeoPackage was built to solve these problems.
A GeoPackage (.gpkg) is a geospatial file format defined through an open standard by the Open Geospatial Consortium (OGC) starting in 2014. It uses a database technology called SQLite to store vector features, raster tile sets, and attribute data all in a single self-contained file. GeoPackage is quickly becoming a go-to format for professionals who need a reliable, portable way to store and share spatial data that’s interoperable between platforms like QGIS, ArcGIS, and Touch GIS.
Read on for a breakdown of what a GeoPackage is, how it compares to the formats you already know, and when you should consider using one.
How a GeoPackage Works
Under the hood, every GeoPackage file is a SQLite database. SQLite is a widely used, lightweight relational database engine that stores everything in a single file. That means a GeoPackage is really just a database with a specific set of tables and conventions defined by the OGC standard.
When you open a .gpkg file, the data inside is organized into tables. Each table can hold a different layer, complete with its own geometry type, coordinate reference system, and attribute columns. Because the file is written for processing by SQLite, you need a specialized program to read the data, but you’re not restricted to GIS applications, any SQL database reader will work just fine. There are a number of optimizations to make interacting with GeoPackages fast and easy. For example, geometries are stored in a compact format called Well-Known Binary, another open standard maintained by the OGC. Spatial indexing can also be added using a technique known as R-trees, so queries that filter by location perform well even on large datasets.
To summarize: it's one file that efficiently includes both vector and raster data with all different types of attributes, as well as spatial reference system information, and it's based on a well-understood, public specification.
GeoPackage vs. Shapefile
Shapefiles have been the default vector format in GIS for decades, and they're still everywhere despite their well-documented limitations. Here's how they compare:
Single file vs. multiple files. A Shapefile is actually a collection of at least three mandatory files (.shp, .shx, .dbf) and often several more (.prj, .cpg, .sbn, .sbx). If you forget to include one when sharing data, things break silently (or loudly). A GeoPackage is always one file.
Field name length. Shapefiles are limited to 10-character field names because of their design constraints. GeoPackage has no official character limit on field names, so you can use descriptive names like vegetation_cover_percentage instead of cryptic abbreviations like veg_cvr_pc.
File size limits. Each component of a Shapefile is capped at 2 GB. GeoPackage has no practical file size limit for the datasets most people work with.
Multiple layers. A Shapefile holds each geometry type in a separate file, so the more feature classes you have, the more files you’ll need to keep track of. A GeoPackage stores all of them in one file, each in its own table.
Shapefiles aren’t going away any time soon. They're deeply embedded in existing workflows and supported by virtually every GIS tool. But if you have a choice, a GeoPackage can handle the same work with better capabilities and fewer headaches.
GeoPackage vs. KML
KML files are popular for sharing geospatial data visually, especially through Google Earth. They're XML-based, human-readable, and good at describing how data should look on a map. That said, KML has significant limitations when you're more interested in capturing and analyzing complex data rather than presentation. Here's how they compare:
Performance. KML stores stores everything as text, which gets large and slow to parse as feature counts increase. GeoPackage uses binary encoding, which is more compact and faster to read. If you're working with a large number of features or a lot of attribute data, you'll quickly notice the difference in file size.
Separation of data and styling. KML combines data and styling instructions like icon styles, line colors, and label placements. It’s really helpful for quickly sharing a file with someone and knowing that they’ll see exactly what you see when they open it. At time of writing, GeoPackage doesn’t have any official styling extension so styling decisions are left to the application reading it. That said, there may be an official or unofficial styling extensions added in the future that provide similar capabilities to KML.
Attribute handling. KML's <ExtendedData> element lets you attach attributes to features, but the data types of those elements aren’t strictly enforced, so you may get some surprising results when processing it. Since GeoPackage uses a full database engine under the hood, you get properly typed columns like integers, decimals, dates, and booleans that you can rely on, so your data arrives ready for analysis without cleanup.
Indexing. KML files have no built-in indexing capability, which means finding a feature requires you to read the entire file until you find it. Since GeoPackage is built on SQLite, it can find particular features much more quickly, and if the R-tree extension is included, it can find them quickly with spatial queries as well.
KML still makes sense when you need a quick, visual way to share locations. For analysis, data exchange, and complex field collection, GeoPackage is a more capable choice.
GeoPackage vs File Geodatabase
If you work in an Esri environment, you've probably used File Geodatabases (.gdb). They're powerful, well-integrated with ArcGIS, and capable of handling complex data models with domains, subtypes, and relationship classes. How do they compare to GeoPackage?
Openness. File Geodatabases are a proprietary format developed by Esri, so the community doesn’t officially know completely how they work. Developers have reverse-engineered much of the format so that some tools like GDAL and QGIS can read them through community-supported drivers, but write support is limited and behavior can be unreliable. GeoPackage is an open OGC standard, so every tool that supports it is working from the same specification.
Portability. Despite the name, a File Geodatabase is still actually a folder and contains dozens of files. Like Shapefiles, that means zipping before sharing, and the risk of corruption if files get separated. A GeoPackage is a single file you can email, drop into cloud storage, or transfer to a mobile device without worrying about missing components.
Cross-platform compatibility. GeoPackage works across applications like ArcGIS, QGIS, and mobile apps like Touch GIS. If your team uses mixed software or if you need to share data with collaborators outside your organization who may not have ArcGIS licenses, GeoPackage removes that barrier.
Where File Geodatabases excel. If you need advanced ArcGIS-specific features like topology rules, geometric networks, annotation classes, or versioned editing, File Geodatabases remain the right tool. GeoPackage is designed for interoperability, so they may not always support the latest-and-greatest features from all software vendors.
For most field collection and data-sharing workflows, GeoPackage gives you the interoperability of an open standard with enough capability to handle the job.
What Applications Support GeoPackage?
GeoPackage has been widely adopted, and support continues to rise. QGIS uses GeoPackage as its default vector format. Esri's ArcGIS Pro and ArcGIS Online support the base specification. GDAL/OGR, the library behind most geospatial data conversion tools, includes a native GeoPackage driver. Programming environments like Python (via GeoPandas, Fiona, and sqlite3 ) and R (via the sf package) can handle .gpkg files natively.
On the mobile side, Touch GIS supports importing and exporting GeoPackage files, making it straightforward to move data collected in the field between your mobile device and desktop GIS. You can export your field data as a .gpkg and hand it directly to a colleague using QGIS or ArcGIS, no format conversion needed. You can also import GeoPackage files shared by your team and take them into the field for reference or further data collection.
This cross-platform support is one of GeoPackage's strongest selling points. When your data needs to move between desktop software, mobile apps, and web platforms, using an open standard eliminates conversion friction.
When to Use a GeoPackage
While GeoPackage isn't always the answer, it's an excellent choice in a growing number of situations and is a safe default choice.
Sharing data between platforms. If you're passing data between QGIS, ArcGIS, mobile apps, or custom tools, GeoPackage is an interoperable format that all of them understand. No format conversion, no lost attributes, no missing projection files.
Working with larger datasets. If you've bumped into Shapefile's 2 GB limit or KML's performance problems at scale, GeoPackage handles those situations without breaking a sweat.
Field data collection. The efficiency, compactness, and reliability of Geopackages make them an excellent choice on mobile devices where ease-of-use is king and processing speed and battery power can be limited. It transfers cleanly over email, cloud storage, or any file-sharing tool.
Where GeoPackage is less ideal: if you need cloud-native streaming, formats like FlatGeobuf or GeoParquet are designed for that. If you need a quick, visual share for someone using Google Earth, KML is still the simpler option at time of writing.
Getting Started
If you're used to working with Shapefiles or KML, switching to GeoPackage is straightforward. Most GIS tools can convert between formats with a few clicks, and many can open .gpkg files with no setup at all.
For field work, Touch GIS makes it simple: collect your data, export it as a GeoPackage, and share the single file with your team. On the desktop side, QGIS and ArcGIS can open it immediately. The data arrives with all its layers, attributes, and coordinate reference information intact. With a few extra steps, you can even view your collected photos directly in QGIS or ArcGIS.
The OGC GeoPackage standard is open, well documented, and actively maintained (currently at version 1.4). If you want to understand more the technical details, the full specification is available at geopackage.org.