Short answer

Web GIS and desktop GIS are not competitors; they occupy different ends of the same pipeline. Desktop GIS (QGIS, ArcGIS Pro) is where data is inspected, edited, analysed, and styled with the full processing toolbox on a local machine. Web GIS is where a curated subset of that work is published to many users in a browser, served as tiles or through an API and optimised for read access, interactivity, and scale rather than heavy computation. Most real projects use both: you analyse on the desktop and publish to the web, and the interesting decisions are about where each part of the workflow lives.

The architectural difference, not just the interface

The deepest distinction is where the rendering and computation happen.

In desktop GIS, everything happens on one machine with direct file access. QGIS or ArcGIS Pro reads a GeoPackage, Shapefile, or GeoTIFF from disk (or a PostGIS connection), holds geometry in memory, runs Processing algorithms against the CPU, and draws the map in a local rendering engine. There is no network round-trip, no tile pyramid, no client/server split. This is why desktop tools handle multi-gigabyte rasters, complex topology edits, and a thousand-step Processing model that a browser never could.

In web GIS, the data has to cross a network to reach a browser that cannot load a 5 GB raster or run a viewshed. So the architecture splits: a server (a tile server, a feature API, or a cloud service) holds the data and exposes it in browser-sized pieces, and a client library (MapLibre GL, Leaflet, OpenLayers, the ArcGIS Maps SDK) requests and renders those pieces. Everything in web GIS is shaped by that constraint — the need to deliver small, cacheable units of data to many simultaneous, low-powered clients.

How web GIS delivers data: tiles and APIs

Three delivery models dominate, and choosing among them is a core web-GIS decision.

Raster tiles (XYZ / WMTS). The map is pre-rendered server-side into 256×256 (or 512×512) PNG/JPEG images organised in a z/x/y pyramid. The browser just stitches images. Pros: dead simple, extremely cache-friendly behind a CDN, predictable load. Cons: styling and labelling are baked in at render time, so changing a colour means re-rendering the pyramid, and you cannot easily query a feature the user clicks. Best for basemaps and stable thematic layers. WMS, by contrast, renders images on demand per request — flexible but harder to cache.

Vector tiles (MVT, the Mapbox Vector Tile spec). The server ships compressed geometry and attributes per tile; the client styles and draws them. Pros: dynamic restyling without re-rendering, crisp at any zoom and on high-DPI screens, feature-level interactivity (hover, click, filter), smaller payloads for line/polygon data. Cons: more client CPU/GPU, a real style specification to manage, and a generalisation step (simplification per zoom level) to get right. PostGIS can emit MVT directly with ST_AsMVT, which is why a PostGIS + tile-server + MapLibre stack is so common.

Feature APIs (OGC API – Features, WFS, ArcGIS Feature Service). The client requests actual features as GeoJSON within a bounding box. Best for editable, queryable layers of modest size; it underpins web editing.

Where each tool genuinely wins

Desktop GIS is the better choice when you need the full Processing toolbox (interpolation, terrain derivatives, network analysis), precise cartographic control for a print layout, topology-aware editing, or you are working with large local rasters and vectors. It is also where you build and debug the analysis before anything gets published.

Web GIS is the better choice when the deliverable is broad read access, an interactive dashboard, field data collection, or a public map. Stakeholders who will never install QGIS can still explore a slippy map, toggle layers, and click features.

The shared backbone is often PostGIS. It serves both: the desktop analyst connects directly for editing and queries, and the same database feeds the web tier via ST_AsMVT or a feature API. Putting data in a spatial database rather than loose files is frequently what makes the desktop-to-web handoff clean.

A decision framework

Do not ask "QGIS or a web map?" — describe the lifecycle and place each stage:

  1. Acquisition and cleaning. Usually desktop + GDAL/Python scripts. Define the CRS discipline here once.
  2. Analysis. Desktop GIS or scripted (Python/processing, R). Keep it reproducible; named outputs, not temporary layers.
  3. Storage. Loose files for a solo, one-off job; PostGIS once several people or products share the data.
  4. Repeatable processing. Move anything that must rerun (nightly imports, batch reprojection) into GDAL/Python or SQL — not manual desktop clicks.
  5. Publication. Pick the delivery model: raster tiles for stable basemaps, vector tiles for interactive thematic data, a feature API for editable layers.
  6. Prototype the riskiest step first — usually performance of the web tier at the real data volume, or a thorny styling/generalisation requirement.

Choose the simplest combination that still lets another analyst audit and extend it.

Common pitfalls and why they happen

  • Trying to do analysis in the browser. Web clients are rendering engines, not GIS engines; heavy computation belongs server-side or on the desktop. Teams hit this when they treat a web map as a full GIS.
  • Publishing raster tiles when the layer needs to change often. Every restyle re-renders the whole pyramid. If styling is fluid or interactivity is needed, vector tiles are the right model.
  • Skipping generalisation in vector tiles. Shipping full-resolution geometry at low zoom produces huge tiles and a sluggish map. Simplify per zoom level (ST_SimplifyPreserveTopology or built-in MVT clipping/simplification).
  • Choosing a web library before deciding the data model and tile strategy. The stack should follow the data architecture, not the other way around.
  • Buying or rejecting a tool on licence cost alone. QGIS is free and capable; ArcGIS offers an integrated server stack. The right answer depends on team skills, support needs, and the publishing target — not price in isolation.

QA and validation

Before a web GIS deliverable ships: confirm the served CRS (web tiles are almost always EPSG:3857, so reproject upstream — and never use 3857 for measurement); test at the real data volume, not a 100-feature sample; check tile sizes and load times at multiple zooms; verify that what the desktop analyst sees matches the web rendering (same data, same generalisation expectations); and confirm the handoff is documented so the web layer can be rebuilt from the source database, not from one person's memory.

Bathyl perspective

We pick the stack from the workflow outward, not from a brand preference. A typical shape is desktop analysis feeding a PostGIS source of truth, scripted pipelines for anything repeatable, and vector or raster tiles for the web tier — chosen so the same data answers both the analyst's deep questions and the stakeholder's quick ones, and so any stage can be rebuilt and audited.

Related reading

Sources