Why is my QGIS buffer the wrong size or distorted?

Almost always because the layer is in a geographic CRS like EPSG:4326, where coordinates are degrees. A 500 'unit' buffer then means 500 degrees of arc, and the ellipse stretches because a degree of longitude shrinks toward the poles. Reproject to a metric projected CRS first.

What CRS should I use before buffering in QGIS?

A projected CRS in metres covering your study area: a local UTM zone (e.g. EPSG:32631), a national grid (EPSG:2154 for France, EPSG:27700 for Britain), or an equidistant/equal-area projection for very large areas. Then a buffer distance entered in metres is true ground distance.

How do I buffer a layer that is in EPSG:4326?

Reproject it with the Reproject Layer algorithm (or set the project CRS and use 'Save As' to a projected CRS), buffer in metres, then reproject back if the destination needs lat/long. Do not buffer directly in degrees.

Should I use a geodesic buffer or a projected buffer?

For local work a projected metric buffer is accurate and simplest. For continental or global extents where no single projection keeps distance true, use a geodesic approach so the buffer respects the ellipsoid rather than a flat projection's distortion.

QGIS Buffer Without CRS Mistakes

Short answer

A buffer is only as correct as the coordinate system it runs in. QGIS's Buffer algorithm interprets the distance you type in map units — the units of the layer's CRS. If the layer is in a geographic CRS such as EPSG:4326 (WGS 84), those units are decimal degrees, so a "500" buffer is 500 degrees, and the resulting ellipse is grossly oversized and squashed because one degree of longitude is about 111 km at the equator but only ~71 km at 50° latitude. The fix is to reproject to a projected CRS in metres before buffering, enter the distance in metres, and validate the result against a known measurement.

Why degrees break buffers

A geographic CRS measures position as angles on the ellipsoid. Distances between two points are not constant per degree: longitude lines converge toward the poles. When QGIS buffers a point in EPSG:4326 by a fixed degree value, it adds the same number of degrees in every direction. Because a degree east is shorter than a degree north (away from the equator), the circle becomes an ellipse, taller than it is wide, and the "radius" has no consistent metric meaning. A buffer meant to be 500 m might become tens of kilometres in one axis and something else in the other.

Projected CRSs (UTM, Lambert Conformal Conic, national grids) flatten a region onto a plane in metres, so within their valid zone a buffer distance in map units is a real ground distance with low, bounded distortion.

Choosing the right projected CRS

Pick a projection whose distortion is small over your area and that preserves distance reasonably:

Local / regional work (best default): the local UTM zone. Find it from longitude — zone = floor((lon + 180) / 6) + 1. Western Europe near 3°E is zone 31N, EPSG:32631. UTM keeps scale error under ~1 part in 1000 within a zone.
National grids: EPSG:2154 (RGF93 / Lambert-93, France), EPSG:27700 (OSGB36 / British National Grid), EPSG:25832 (ETRS89 / UTM 32N, much of Germany). These match official data and avoid zone-edge issues.
Large / continental extents: an equidistant projection (e.g. an Azimuthal Equidistant centred on the area) if distance from a centre matters, or a geodesic buffer instead of any single projection.

Avoid Web Mercator (EPSG:3857) for buffering: it is conformal but its scale factor grows with latitude, so a "1000 m" buffer near 60° N is far from 1000 m on the ground.

The reproject-then-buffer workflow

Inspect the CRS. Layer Properties > Information, or read the EPSG code in the status bar. If it is 4326, 4258, or any code described as "geographic", you must reproject.
Reproject the layer. Processing > Reproject layer (native:reprojectlayer), target the projected CRS, save to a named GeoPackage rather than a scratch layer. From the command line, GDAL does the same:
```
ogr2ogr -t_srs EPSG:32631 sites_utm.gpkg sites_wgs84.geojson
```
Buffer in metres. Processing > Buffer (native:buffer). Set Distance to 500 (metres), Segments to 8 or higher for smooth curves, and decide on Dissolve result if you want overlapping buffers merged into one polygon.
Reproject back if needed. If the deliverable must be WGS 84, reproject the buffer output to EPSG:4326 — accuracy is already baked in because the geometry was built in metres.

In PostGIS the equivalent is to transform, buffer, transform back:

SELECT ST_Transform(ST_Buffer(ST_Transform(geom, 32631), 500), 4326)
FROM sites;

Or use the geography type, where ST_Buffer(geom::geography, 500) measures in metres on the ellipsoid directly.

Geodesic vs projected buffers

When your data spans many UTM zones or the whole globe, no single projected CRS keeps distance honest everywhere, so the projected approach distorts at the edges. A geodesic buffer computes the offset on the ellipsoid itself. QGIS does not expose a one-click geodesic buffer in core processing, but you have options: enable ellipsoidal measurement in Project Properties > General so measured distances are geodesic for QA; buffer per-zone and merge; or use the PostGIS geography type, which is inherently geodesic. For most site-, parcel-, and basin-scale work a projected metric buffer is accurate to well under a metre and is the right tool.

Worked example: 250 m setback around boreholes

You receive boreholes as a GeoJSON in EPSG:4326 and must draw a 250 m exclusion buffer.

Reproject layer boreholes to EPSG:32631 (the site is near 4°E, 51°N).
Buffer, distance 250, segments 12, dissolve = no (keep one buffer per borehole for attribute joins).
Measure one buffer with the Measure tool (with ellipsoidal measurement on) — diameter should read ~500 m.
Reproject the buffer back to EPSG:4326 for the web map.

If you had skipped step 1 and buffered 250 in the original CRS, every "buffer" would have been a 250-degree blob covering most of the planet — an obvious failure, but the subtler failure is buffering by a small fractional degree (say 0.0025) and shipping silently wrong, non-circular setbacks.

Common pitfalls and why they happen

Buffering in EPSG:4326 with a small degree value. Looks plausible, produces an ellipse with the wrong radius and wrong shape. The cause is unit confusion: map units are degrees, not metres.
Web Mercator buffers far from the equator. EPSG:3857's scale inflation makes high-latitude buffers too large. Use a local projected CRS instead.
Negative or zero results on lines/polygons. A negative buffer (inward) larger than the feature's half-width erases it. Check geometry size before shrinking.
Jagged buffer edges. Segments set too low; raise it (8–16) to approximate the arc.
Distance entered for the wrong layer. A reprojected layer pointing back at the geographic source via a virtual layer can re-introduce degrees. Buffer the materialised projected file.

QA and validation

Turn on ellipsoidal measurement (Project Properties > General > Measurements) and measure the buffer width — it should equal twice your distance within centimetres. Compare against a control: a feature whose real-world setback you know, or the OGC/GDAL result from the same input. Confirm the output CRS in Layer Properties matches your intent, and check buffer area with the field calculator ($area) against the analytical value (π r² for a single point buffer) to catch unit errors before they reach a map or a legal setback document.

Bathyl perspective

CRS discipline is the difference between a buffer that means "250 metres on the ground" and one that means nothing. We standardise on a documented project CRS, reproject inputs explicitly before any metric operation, and record the EPSG code in the output metadata so a setback, hazard ring, or proximity zone can be defended later.

QGIS Buffer Analysis Without CRS Mistakes