qgis2web, turning a QGIS project into a Leaflet or OpenLayers webmap

What the plugin copies out of your QGIS project

The point of qgis2web is that the map already exists in QGIS, so exporting it should not mean rebuilding it in a different tool. The README states that it replicates as many aspects of the project as it can, and names them: layers, extent and styles, including categorized and graduated styles. That last clause is the important one, because a plugin that only handled simple line and fill symbology would be a toy, while categorized rendering means a rule-based style on a layer becomes a JavaScript style function in the output, and graduated rendering means a classed numeric ramp becomes a lookup by value. Everything is driven from the QGIS interface. You run the plugin from the Web menu or from its icon on the Web toolbar, and the dialog it opens is where you pick the export options, with the README noting that all options are written into your QGIS project so saving the project keeps the settings.

Preparing symbology, aliases and popups before you export

The documentation is unusually specific about the preparation work, which tells you where the friction lives. You set the project title, abstract, background and highlight colours under Project > Properties, in the General and Metadata pages. You give layers human-friendly names in the Layers Panel and give columns friendly names under Layer > Properties, in the Attributes Form, Fields and Alias area. Two widget-type changes control the popups: setting a field's Widget Type to Hidden keeps it out of the popup, and setting it to Attachment puts media in the popup, provided the field holds the image path. Styling itself is done to the wiki's instructions, and scale-dependent visibility is supported when a layer should only appear above or below a certain scale. All of this means the exported map's labels come from your QGIS project rather than from a second round of editing in the output.

Two export targets and two very different front ends

The repository makes the two-target design obvious from the file layout. There is a leaflet/ directory alongside an openlayers/ directory, and the writers are separated into leafletWriter.py and olwriter.py with matching script generators, so a Leaflet export and an OpenLayers export are produced by two different code paths rather than one generalised layer. The library credits make the same point in the dependency list. Leaflet builds pull in Leaflet.label, Leaflet.Locate, Leaflet.markercluster, leaflet-measure, leaflet-hash, leaflet-search, Leaflet.pattern, Leaflet.VectorGrid, Leaflet.Control.Layers.Tree and Leaflet.SvgShapeMarkers, while the OpenLayers side has ol-layerswitcher and ol-search-layer. Shared pieces include proj4js, which handles coordinate system reprojection in the browser, and Autolinker.js. The practical consequence is that the Leaflet export tends to be the lighter default and the OpenLayers export is the one to pick when the map needs richer layer control or a different projection story.

The npm manifest is a leftover, not the version to trust

The package.json in the repository root is worth reading only to understand what the JavaScript side depends on:

{
  "name": "qgis2web",
  "version": "2.99.0",
  "dependencies": {
    "leaflet": "1.1.0"
  }
}

There is a single dependency, leaflet pinned at 1.1.0, and a version string of 2.99.0. That version number does not correspond to the plugin's release history, which the release list puts at v4.4.0 published on 2026-09-18, with v4.3.0 for PBF vector tile export on 2026-07-06 and v4.2.1 on 2026-06-26. The manifest is not how the plugin is distributed, since the plugin is installed from the QGIS plugin repository, so treat 2.99.0 as an artefact of an old packaging path rather than as a version to quote in a bug report. It also tells you that the bundled Leaflet runtime is an old 1.1.0 build, so if you plan to customise the generated JavaScript you are working against a Leaflet that predates current releases.

GeoJSON export needs no server, PBF export starts one

The server story differs by output format, and this is the single most important operational fact about the plugin. For GeoJSON export, the README says no server-side software is required, which means the result is a folder of files you can put on any static host. For PBF vector tile export, the plugin includes a local server launcher and Python is required, because a tiled format has to be sliced and served rather than handed over as one file. So the plugin will ask you for a Python environment in exactly the case where your data is large enough to need tiling, which is an unfortunate correlation but a fair trade. The repository also carries an FTP export path, credited to a contributor for use with Faunalia and ENEL, and the interface includes an FTP configuration form, so a result can be pushed to a remote host rather than copied by hand.

Two ways to install, and what the Makefile is for

Installation happens inside QGIS. The documented route is to select Plugins > Manage and Install Plugins in QGIS, find qgis2web in the list, and install it. The alternative is to download the master repository archive from github and use the Install from ZIP option in the same plugin manager dialog. The project is published on the QGIS plugin repository, whose page is the plugin's homepage. The Makefile at the repository root is a translation and packaging helper rather than the build for the plugin itself, and it shows the shape of the source tree: SOURCES lists __init__.py, qgis2web_mod.py and qgis2web_mod_dialog.py, UI_FILES lists the Qt Designer forms, EXTRAS is icon.png and metadata.txt, and COMPILED_RESOURCE_FILES is resources_rc.py. A LOCALES variable controls which locale translations are compiled, and it is empty by default, which means no translations are built unless you opt in.

Where qgis2web is the wrong tool

The wrong-tool case is a production web GIS. qgis2web produces a generated static webmap: HTML, JavaScript and data files that you upload. There is no server application, no database, no user model, no tile pipeline that rebuilds itself when the source data changes, and no query or routing capability. Regenerating the map means running the plugin again in QGIS and redeploying the output, so any data that changes daily needs a different pipeline. The second limit is the fidelity of the translation, and it runs both ways: a QGIS project can express things a webmap cannot reproduce, and the plugin's own guidance to use simple symbologies is an admission that complex QGIS styling will not survive the trip. The third limit is the size of the data, since a GeoJSON export of a large layer delivered to a browser is a real performance problem, which is precisely why the PBF vector tile path exists.

Licence, governance and who maintains it now

The plugin is distributed under the GNU General Public License version 2, and the same notice is repeated in the header comment of the Makefile, which carries the original 2015 copyright of Riccardo Klinger. Because it is a QGIS plugin rather than a hosted service, the GPL obligations attach to the code you redistribute, and the generated output is your own map data, so there is no licensing surprise for a public map. On people, the README is unusually explicit: Tom Chadwin is the author and was the official developer from April 2015 to November 2023, and from that date Andrea Ordonselli took over. The project also documents its own origins as a merge of Victor Olaya's qgis-ol3 and Riccardo Klinger's qgis2leaf, and it asks for donations to fund continued development, with a plugin as a donor thank-you gift.

Editorial conclusion

qgis2web suits a GIS practitioner who needs to publish a map quickly and already works in QGIS, and it is a good fit for a static map that will not change often or a prototype handed to a stakeholder. It is the wrong tool for a production web GIS that needs live data, user accounts, routing or a query service, because what it produces is a generated static site, not a server application. Verify first that your symbologies are simple before exporting, since the documentation asks you to prepare the map with simple symbologies, check the output format you pick against how large your layers are, and note that PBF vector tile export needs Python because it launches a local server. The last push was on 2026-09-18 and version v4.4.0 was published the same day.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. qgis2web/qgis2web on GitHub
4. README
5. Releases