How the ST_Transform Reprojection Tool works, and what it assumes
ST_Transform converts every position of a geometry from one coordinate reference system to another. The source system comes from an EWKT SRID prefix, from the Source SRID field, or, for GeoJSON, from RFC 7946, which defines GeoJSON as EPSG:4326; the page always says which it used, and plain WKT without a source SRID is refused rather than guessed at. Both systems must be in the site's offline EPSG subset, the same definitions the EPSG Lookup shows, and the arithmetic is done by proj4js.
A change of projection alone is exact to floating-point precision. A change of datum is where accuracy is decided, and every result states which case applied. WGS 84 and the datums aligned with it, such as ETRS89, NAD83 and GDA94, are treated as coincident, as PROJ does without a time-dependent transformation, which is good to about 1 to 2 m. Datums with published Helmert parameters, such as OSGB36, ED50, DHDN and Amersfoort, are shifted with them, typically good to a few metres. NAD27 needs grid files a browser tool does not have, so it is refused instead of being shifted by nothing.
Positions outside the region a projection covers are refused with the reason: Web Mercator ends at 85.0511 degrees of latitude, and Transverse Mercator systems such as UTM are refused more than 9 degrees from their central meridian. Every result is also transformed back and compared with the input, which catches anything else a projection cannot represent. As in PostGIS, only vertices are transformed; the straight edges between them are not densified.
Where this comes up in GIS work
- Converting GPS or GeoJSON coordinates into the national grid a client's CAD or survey data uses.
- Getting Web Mercator metres for tile and pixel calculations.
- Moving a geometry into a UTM zone to measure or buffer it in metres.
- Checking what a database's ST_Transform should return for a known geometry.
A worked example
A building footprint in central London, from WGS 84 to British National Grid:
SRID=4326;POLYGON ((-0.1283 51.5080, -0.1270 51.5080, -0.1270 51.5089, -0.1283 51.5089, -0.1283 51.5080))
→ SRID=27700;POLYGON ((529992.343 180445.928, 530082.556 180448.236, 530079.994 180548.319,
529989.783 180546.011, 529992.343 180445.928))
The OSGB36 datum shift uses the Helmert parameters in the EPSG definition, so the page notes that the result is good to a few metres, not to the centimetres of the OSTN15 grid. Without a datum change the result is exact: POINT (-0.1276 51.5072) in Web Mercator is POINT (-14204.367 6711506.705), and POINT (13.405 52.52) in ETRS89 / UTM zone 33N (EPSG:25833) is POINT (391779.259 5820072.159).
Using the ST_Transform Reprojection Tool
- Paste a geometry as EWKT, WKT or GeoJSON, or select Load example.
- Enter the source SRID, unless the input is EWKT with an SRID prefix or GeoJSON, which is EPSG:4326 by definition.
- Enter the target SRID, such as 3857, 27700 or a UTM zone like 32633.
- Choose the output format and decimal places, then select Transform geometry or press Ctrl + Enter (Cmd + Enter on a Mac).
- Read the accuracy statement, then copy or download the result.
When the output looks wrong
- WKT does not say which coordinate system it is in
- Plain WKT carries no CRS, and the tool will not guess one. Enter the Source SRID, or paste EWKT with an SRID= prefix.
- A system is on the NAD27 datum
- Moving to or from NAD27 needs the NADCON or NTv2 grid files, and without them the shift would silently be zero, tens of metres wrong. The tool refuses rather than return that; use PostGIS, GDAL or PROJ with the grids installed.
- A position cannot be represented in the target system
- It is outside the region the target projection covers: beyond 85.06 degrees of latitude for Web Mercator, or more than 9 degrees from the central meridian of a UTM zone or Transverse Mercator grid. Choose a system that covers the data.
- The result is a few metres from my GIS software's
- The datum shift used a Helmert transformation, accurate to a few metres, where your software may use a national grid such as OSTN15. The accuracy note under the result says which method was used.
Questions about the ST_Transform Reprojection Tool
Which coordinate systems are supported?
The two hundred or so systems in this site's offline EPSG subset: WGS 84, Web Mercator, every WGS 84, ETRS89, NAD83 and GDA UTM zone, and the major national grids. The EPSG Lookup lists them. Codes outside the subset are refused rather than guessed.
How accurate is the transformation?
Projection formulas alone are exact to floating-point precision. A datum change is exact only in name for WGS 84-aligned datums such as ETRS89 and NAD83, which are treated as coincident, good to about 1 to 2 m; datums with Helmert parameters, such as OSGB36 or ED50, are typically good to a few metres. Every result says which applies.
Which axis order is used?
x then y, as PostGIS writes it: longitude then latitude, or easting then northing, whatever axis order the EPSG registry defines for the system.
Are the edges between vertices curved to follow the projection?
No. As in PostGIS, only the vertices are transformed and the edges between them stay straight. Long edges in one system are slightly curved in another; add vertices along them first if that matters.
Is my data uploaded?
No. The transformation is computed in your browser with proj4js, loaded from this site.