How do I package a QGIS project so it opens on another machine?

Run Processing ▸ Package Layers to consolidate every layer into a single GeoPackage, save the project as a compressed .qgz alongside it using relative paths, embed layer styles, and include any required fonts and a metadata note. The recipient then has one .gpkg and one .qgz.

What is the difference between .qgz and .qgs?

.qgs is a plain-text XML project file. .qgz is a zipped container holding that XML plus auxiliary data such as embedded SQLite settings and the layout's images. For delivery, .qgz is preferred because it is a single compact file.

How do I bundle all layers into one GeoPackage?

Use the Processing algorithm Package Layers (native:package). It writes every loaded vector layer into one .gpkg, optionally exporting styles to the GeoPackage's layer_styles table and saving a project file that points at the consolidated data.

Why are my layers showing as broken paths after I move the project?

The project stored absolute paths to data that no longer exist at that location. Save the project with relative paths, keep data and project in the same folder tree, or consolidate everything into one GeoPackage so there are no external references to break.

QGIS Package Project for Delivery: GeoPackage & QGZ

Short answer

Delivering a QGIS project that opens cleanly on someone else's machine means eliminating external dependencies. The reliable recipe is: Processing ▸ Package Layers to fold every layer into one GeoPackage, save the project as a compressed .qgz with relative paths, embed the styles, and bundle any non-standard fonts and a short metadata note. Done right, the recipient receives two files — project.qgz and data.gpkg — and double-clicking the project just works.

Why projects break on hand-off

A QGIS project file does not contain data. It contains references — file paths, database connection strings, WMS URLs — plus styling and layout. When you move or send the project, every reference must still resolve. The three things that break a hand-off are:

Absolute paths. If the project stored C:\Users\you\survey\dem.tif, the recipient sees a red broken-layer icon.
Scattered data. Twenty Shapefiles across five folders, half of them network drives.
External services and assets. A PostGIS connection only you can reach, an SVG marker stored in your personal symbol library, or a font the recipient does not have installed.

Packaging removes all three by consolidating data, internalising styles, and making paths relative.

Step 1 — Consolidate data with Package Layers

The single most useful tool here is Processing ▸ Toolbox ▸ Package Layers (native:package). It writes every selected vector layer into one GeoPackage (.gpkg), an OGC standard SQLite container that holds many vector layers, attribute tables, and even styles in a single file.

Set the options:

Save layer styles into GeoPackage: yes — this writes each layer's symbology to the GeoPackage layer_styles table so colours travel with the data.
Save only selected features: usually no, unless you are delivering a subset.
Export related layers: yes if you use relations.

For rasters, Package Layers handles vectors; bring rasters into the same delivery folder as Cloud-Optimized GeoTIFFs or tiled GeoTIFFs:

gdal_translate dem.tif dem_cog.tif \
  -of COG -co COMPRESS=DEFLATE -co PREDICTOR=2

A COG keeps the raster a single self-describing file with internal overviews, so it pans and zooms fast without a separate pyramid file. GeoPackage can store rasters too, but for large terrain a COG alongside the .gpkg is usually more practical.

Step 2 — Save as .qgz with relative paths

Before saving, set Project ▸ Properties ▸ General ▸ Save paths to Relative. With relative paths, the project references ./data.gpkg rather than an absolute drive path, so the whole folder can move anywhere.

Then Project ▸ Save As and choose the .qgz format. A .qgz is a ZIP archive containing the .qgs XML plus an auxiliary SQLite store (.qgd) and layout assets. It is one compact file instead of a project plus loose sidecars, and it compresses the XML. Use plain .qgs only when you need the project under version control as readable text (XML diffs cleanly; the zipped .qgz does not).

Keep the project file in the same folder as the GeoPackage and any rasters. A clean delivery folder looks like:

survey_delivery/
  project.qgz
  data.gpkg          # all vectors + styles
  dem_cog.tif        # terrain raster
  fonts/             # any non-standard fonts
  README.txt         # CRS, source, date, contact

Step 3 — Embed styles, fonts and SVGs

Styles stored in the GeoPackage layer_styles table travel automatically. But SVG markers and fonts are referenced, not embedded, by default:

For SVGs, either replace them with built-in simple-marker symbols, or set Settings ▸ Options ▸ System ▸ SVG paths expectations aside and use Embed where the symbol dialog offers it. The safest path for critical custom glyphs is to convert them into the symbol or include the SVG files in the delivery folder with a relative SVG search path.
For fonts, QGIS substitutes a default if the named font is missing, silently changing your labels. Either stick to widely available fonts, or include the font files in fonts/ and tell the recipient to install them. The layout export to PDF/SVG can embed fonts, but the editable project cannot.

Step 4 — Layouts and metadata

If you ship print layouts, confirm each layout map item still references a valid layer and that the layout's images (logos, north arrows) are embedded or in the folder. Export a PDF/SVG of each layout as a "what it should look like" reference so the recipient can verify their rendering matches yours.

Finally, write a short metadata note (the README.txt above, or use Layer ▸ Properties ▸ Metadata per layer): project CRS (with EPSG code), data sources and dates, processing summary, and a contact. This is the difference between a deliverable someone can audit and a black box.

Common pitfalls and why they happen

Red broken-layer icons on the recipient's machine. Absolute paths plus scattered data. Re-save with relative paths after Package Layers; verify by moving the folder yourself and reopening before you send it.
Labels look different after delivery. A missing font was silently substituted. Bundle the font or use a standard one.
Custom markers became plain squares. SVGs were referenced from your personal profile, not the project. Embed or include them.
GeoPackage locked / "database is locked" errors. Two QGIS sessions, or QGIS plus an external tool, held the SQLite file open. Close other connections; GeoPackage is single-writer.
Huge .qgz on disk. You embedded large rasters into the project. Keep big rasters external as COGs and reference them relatively.
Recipient's CRS prompts. Bundle a .txt stating the project CRS so they do not guess; if you used a custom CRS, that definition must be re-created on their side — prefer a standard EPSG code.

Validation: open it the way the recipient will

The only trustworthy test is to copy the delivery folder to a different path (or another machine / a fresh QGIS user profile) and open the .qgz. Check: no broken layers, styles intact, labels in the right font, layouts render, and the CRS reads correctly. A quick way to sanity-check the GeoPackage contents is ogrinfo -so data.gpkg to list layers and confirm the styles table exists.

Bathyl perspective

We package every deliverable as if the recipient has none of our tooling and we will never explain it in person. That means one GeoPackage, a relative-path .qgz, COG rasters, bundled assets, and a metadata note stating CRS, source and date. The test is simple: copy the folder somewhere new, open it cold, and confirm nothing is red. A project that survives that move is a project a client can keep.

QGIS Package Project for Delivery