From QGIS to the web: five ways to share a map online

Every GIS team has the same last mile. The analysis is finished, the layers are styled, the project file is exactly the way you want it — and then someone in another department asks whether they can have a look. So you export a PDF, attach it to an email, and the map stops being a map. It can't be zoomed, queried or filtered, nobody can click a feature to see its attributes, and three weeks later it is quietly out of date while still circulating as the truth.

Publishing a QGIS project to the web is a solved problem in the sense that there are several genuinely good answers. It's an unsolved problem in the sense that they're rarely compared honestly. Each one carries a different amount of infrastructure to run, a different update loop, and a different answer to the question of who is allowed to look. Below is the whole field, roughly ordered by how much of it lands on your plate.

The five options at a glance#

1. Export an image or a PDF#

The default, and there is nothing wrong with it for what it's actually good at: a fixed figure in a report, a printed wall map, an appendix to a planning decision. QGIS's print layout composer is excellent, and a well-made PDF beats a badly made web map for a document that needs to be archived exactly as it was.

It fails the moment the map is meant to be used. Readers can't turn layers on and off, can't find their own property, can't check an attribute. And every export is a fork in the road — the version in someone's inbox never catches up with the version in your database. If you find yourself re-exporting the same map monthly, that's the signal to move up this list.

2. qgis2web — a static web map from your project#

The qgis2web plugin exports the open project to a folder of HTML, JavaScript and data, rendered by Leaflet or OpenLayers. Drop the folder on any web host and you have a live map with popups, a layer switcher and your styling approximated in browser terms. It's free, it takes ten minutes, and for a small public dataset it's a genuinely good answer.

The limits show up quickly. The data is embedded in the page, so the visitor's browser downloads the entire dataset before it draws anything — fine for a few hundred features, painful at ten thousand, impossible at a million. There is no access control at all: anything you export is public to anyone with the URL. And there is no update loop. When the data changes, you re-open QGIS, re-export, and re-upload, which is the PDF problem wearing a nicer coat.

3. QGIS Server — publish the project as OGC services#

QGIS Server reads the same .qgs project file you already have and serves it as standards-based web services: WMS, WFS, WMTS and OGC API Features. Its headline advantage is real and nobody else on this list matches it — the rendering engine is QGIS itself, so your symbology, labelling rules, scale-dependent styling and print layouts come across exactly as you drew them. Pair it with a client such as QGIS Web Client or Lizmap and you get a full web portal. It's also the right answer when other systems need to consume your data as OGC services rather than look at a map.

The cost is operational. You are running a server: a web front end, FastCGI processes, caching, TLS certificates, authentication, backups, OS patching and version upgrades — and when the map is slow at nine on a Monday morning, that's yours too. Plenty of organizations run it happily. Just be honest about whether you have the people, because a QGIS Server that nobody maintains becomes a security liability rather than a service.

4. PostGIS, a tile server and a front end of your own#

The maximal-control option: put the data in PostGIS, serve vector tiles with something like Martin, pg_tileserv or Tegola, and build a front end on MapLibre or OpenLayers. Everything is possible, nothing is provided. This is the right call when the map is a product — when it needs a bespoke interface, unusual interactions or deep integration with a system that already exists.

For an internal "the water department needs to see the network" problem, it is the most expensive way to fail. The first map is months away, and the maintenance never ends: dependency upgrades, browser regressions, whoever built it moving on to another job. Choose this deliberately, not by drift.

5. A hosted GIS platform#

Upload or sync your layers to a platform that handles storage, tiling, styling, access control and publishing, and get a URL back. The trade-off is straightforward: you give up some control and pay a subscription, and in exchange the update loop and the infrastructure stop being your problem. For most teams whose job is making maps rather than running map servers, this is the pragmatic answer — provided you check where the platform actually stores your data, which for European public organizations is not a small question.

What publishing actually has to solve#

Whichever route you take, the same six problems are waiting. It's worth checking a candidate solution against all of them before committing, because the ones people forget are usually four and five.

• Rendering at scale. A national property dataset is not a GeoJSON file. Anything past a few thousand features needs vector tiles and generalized overviews, so the browser draws a manageable slice at every zoom instead of the whole thing at once.
• The coordinate system. Your data is probably in SWEREF 99 TM; the web's default is Web Mercator. Reprojection is unavoidable, but when and where it happens decides whether your areas and distances survive the trip. We wrote about that in detail in SWEREF 99 TM, RT 90 and Web Mercator.
• Who is allowed to look. Most maps are not public. Some are public but reference layers that must not be. The distinction between "internal to my organization" and "on the open web" needs to be a switch you can see and audit — not a URL you hope nobody guesses.
• Keeping it current. This is the real cost, and it's invisible on day one. If updating the published map means re-exporting from the desktop, you will stop doing it. Ask how a corrected attribute reaches the reader, and count the manual steps.
• Editing. Fixing a typo in a field shouldn't require an export, an upload and a redeploy. Somebody has to be able to change the data in the tool where they actually work.
• The reader's experience. Your audience opens the link on a phone, in a meeting, without a login and without a GIS background. If it needs a manual, it won't get used.

How to choose#

• Need a fixed figure for a document? Export it. Don't over-engineer.
• Small, public, static dataset and no budget? qgis2web is the honest answer.
• Do other systems need your data as WMS or WFS, or is pixel-exact QGIS symbology non-negotiable? QGIS Server — if you have someone to run it.
• Is the map a product with bespoke requirements and a development budget? Build it on PostGIS.
• Do you publish regularly, need access control, and want the desktop and the web to hold the same data? A hosted platform.

What this looks like in OrbGIS#

We built OrbGIS for the fifth case, with one specific conviction: nobody should have to abandon QGIS to get their maps online. QGIS is where serious spatial work happens, and a web platform that fights it is a platform people quietly stop using.

So the desktop stays in the loop. The OrbGIS Connector is a free, open-source plugin for QGIS 3.34 and newer — pure Python, no dependencies. You sign in through your browser rather than pasting an API key, and a dock appears listing every feature layer in your organization.

• Publish from QGIS. Drag a vector layer from the QGIS Layers panel onto the dock. It runs through the same ingest pipeline as a web upload — reprojection, indexing, tiling and automatic overviews for large layers — and appears in your portal as a hosted layer.
• Edit where you already work. Add to map pulls a layer into your project as a managed GeoPackage. Edit it the way you always do, then Save Edits pushes the changes back. Editing is lockless: no checkouts, last write wins, and a rejected save flips the layer to an out-of-sync state rather than silently mangling your local copy.
• The web side is a real web map, not an export. Layers render as vector tiles, so a multi-million-feature dataset stays responsive. SWEREF 99 TM, ETRS89-LAEA, EUREF-FIN and the UTM zones 32N and 33N are served natively — no client-side reprojection, no drift.
• Two switches for visibility. Ownership decides who inside your organization sees an item; publishing puts an app on the open web. Before anything goes live, the publish panel lists every dataset that becomes publicly readable so you can say no. See Sharing and publishing.
• Readers need nothing. A published dashboard or journey lives at your own subdomain, opens on a phone, and costs no seat.

One honest caveat: QGIS symbology does not transfer. Styling is applied on the web side, in the map viewer, where it becomes a shared property of the layer rather than something living in one person's project file. That's a deliberate trade — it's also the single thing QGIS Server does better, and if pixel-exact reproduction of a complex QGIS style is your hard requirement, we'd rather you knew that now.

Questions we get asked#

Do I need QGIS Server to publish a QGIS map?#

No. QGIS Server is one route of several, and the only one that reproduces QGIS symbology exactly — but it requires you to run and maintain server infrastructure. A hosted platform, a static qgis2web export, or a custom PostGIS stack all publish maps without it.

Can I keep editing in QGIS after the map is published?#

With a platform that syncs both ways, yes. In OrbGIS the Connector loads a hosted layer into your project, and Save Edits pushes your changes back to the same layer the published map reads from — so the web map reflects the edit without a re-export. With static exports it's the opposite: every change means exporting and uploading again.

Does my QGIS styling come across?#

Only with QGIS Server, which renders using QGIS itself. qgis2web approximates styles in Leaflet or OpenLayers terms and drops what those libraries can't express. Hosted platforms, OrbGIS included, ask you to style the layer on the web side.

What happens to SWEREF 99 TM data on the web?#

It has to be reconciled with the web's Web Mercator default one way or another. The good implementations either serve tiles natively in your projected CRS or reproject once, at load, rather than per frame. The bad ones silently show you Web Mercator areas — which near the Arctic Circle can be several times too large. Our coordinate systems guide covers what to check.

Can several people edit the same layer at once?#

Depends entirely on the backend. A shared GeoPackage on a network drive will corrupt; PostGIS and hosted platforms handle concurrency properly. OrbGIS uses lockless last-write-wins editing — no checkouts to forget to release, and colliding writes fail loudly instead of silently.

Is qgis2web good enough?#

For a few hundred features on a genuinely public map with no update cadence, yes, and you should use it. For anything with access control, regular updates or serious data volume, it isn't — and the effort you'd spend working around those limits is better spent moving up the list.

The right answer depends on how often you publish, how much infrastructure you want to own, and who's allowed to see the result. But the wrong answer is almost always the one you're doing by default: exporting another PDF because the alternative feels like a project.

If you'd like to see the QGIS route end to end, the Connector documentation walks through installation and the first sync — or try OrbGIS free and publish a layer from your own project this afternoon.