Proj4 Coordinate Converter

What Is a Proj4 Coordinate Converter?

A proj4 coordinate converter transforms coordinates between arbitrary projections and datums by interpreting a proj4 string — the classic textual syntax used by the PROJ library and its JavaScript port, proj4js. Where an EPSG-based reprojector is limited to the published EPSG catalog, a proj4 converter accepts any valid proj4 string and can therefore handle custom local grids, oblique projections, historical datums, and obscure national systems that never made it into the EPSG registry.

A proj4 string looks like this: +proj=utm +zone=33 +datum=WGS84 +units=m +no_defs. Each parameter is a key/value pair describing the projection (+proj=utm), its tuning constants (+zone=33, +lon_0=15), the datum or ellipsoid (+datum=WGS84, +ellps=GRS80), and the output units (+units=m, +to_meter=0.3048 for feet). The proj4 grammar is compact, human-readable, and has been the de facto format for cartographic projections since the mid-1990s. It is what GDAL, QGIS, ArcGIS, PostGIS, GeoPandas, Shapely, and rasterio all fall back on when they need to describe a CRS that isn't in EPSG.

This converter runs entirely in the browser using proj4js, the same library that powers reprojection in OpenLayers, Cesium, Turf.js workflows, and many commercial web mapping products. You paste a source proj4 string, a target proj4 string, and either a single coordinate pair or an entire GeoJSON file — and get back transformed data without any upload, install, or server round-trip.

How Proj4 Transformations Work

Parsing the proj4 String

proj4js parses the string into a parameter dictionary, looks up the projection handler (one of several dozen — tmerc, merc, lcc, aea, stere, omerc, utm, latlong, and many more), and instantiates a projection object with the appropriate constants. Each handler implements forward and inverse functions that map between geodetic lat/lon and the projected plane.

Forward and Inverse Projection

To transform from proj4 A to proj4 B, the converter first applies the inverse of A (projected → geodetic), optionally shifts the datum, then applies the forward of B (geodetic → projected). For geographic sources (+proj=longlat) the first step is a no-op. For projected sources the inverse function handles the conic, cylindrical, or azimuthal math — usually a short power series derived from the ellipsoid's eccentricity.

Datum Transformations

If A and B use different datums, a datum shift is inserted between the inverse and forward steps. proj4js supports Helmert 3- and 7-parameter transformations (+towgs84=dx,dy,dz,rx,ry,rz,s) and, for some systems, grid-based shifts via the +nadgrids= parameter. Without a +towgs84 parameter, no shift is applied and the transformation assumes the two datums are identical, which can introduce meter-scale errors in North America or continental Europe.

Key Parameters and Options

Source proj4 String

Paste the source projection definition. Examples:

• +proj=longlat +datum=WGS84 +no_defs — plain WGS84 lat/lon
• +proj=utm +zone=33 +datum=WGS84 +units=m +no_defs — UTM zone 33 N
• +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +units=m +no_defs — British National Grid

Target proj4 String

Paste the target projection definition. Can be any valid proj4 string, including custom oblique Mercators for mining projects, local grids for construction, or historical datums for archaeology.

Datum Shift Parameters

If your source or target uses a non-WGS84 datum, include a +towgs84= parameter or specify +datum= to use a built-in 7-parameter set. Without this, the transformation assumes datums are identical.

Input Data

Paste a coordinate pair, a list, or drop a GeoJSON, CSV, or WKT file. The converter handles all Feature geometry types.

Output Precision

Choose the number of decimal places to emit. Projected units (meters, feet) typically need 1–3 decimals; geographic units (degrees) need 6+ to preserve sub-meter precision.

Practical Applications

Custom Local Grids for Engineering Projects

Mining operations, major construction sites, and infrastructure corridors often use a custom local grid — a rotated transverse Mercator tuned to a specific central meridian and origin, with false easting/northing chosen to produce "nice" site coordinates. These grids are defined by a proj4 string and are never in the EPSG catalog. Our converter handles them directly.

Historical and Legacy Datums

Archaeological excavations, old cadastral plans, and pre-digital geological surveys often reference historical datums like OSGB36, Madrid 1870, Pulkovo 1942, or Tokyo Datum. Recovering the modern-equivalent coordinates requires a proj4 string with explicit +towgs84 or +nadgrids parameters. A proj4 converter is the most straightforward way to apply these transformations without setting up a full PROJ environment.

Oblique Mercator for Linear Features

Pipelines, long fiber runs, railway alignments, and submarine cables benefit from an oblique Mercator projection oriented along the feature's axis, minimizing scale distortion. The proj4 string +proj=omerc +lat_0=... +lonc=... +alpha=... is the only way to describe this precisely, and a proj4 converter lets engineers tune the parameters interactively.

Research Using Non-Standard Projections

Climate scientists using rotated pole grids, oceanographers using cylindrical equal-area projections, and polar researchers using Lambert Azimuthal all work with projections that are in proj4 but not always well-indexed in EPSG. A proj4 converter is their go-to tool for reprojecting model output and observation data into a common analysis frame.

Web Mapping Custom Basemaps

Custom basemaps — especially for internal corporate or government use — sometimes adopt a local projection that needs to be reconciled with Web Mercator for display. A proj4 string describes the source; proj4js in the converter transforms the data to EPSG:3857.

Teaching and Learning

GIS students benefit from being able to tweak a proj4 string and see the result immediately. It builds intuition about scale factors, false origins, and central meridians in a way that clicking through a QGIS dialog does not.

Interoperating with GDAL and PROJ Workflows

If you are building a reprojection pipeline in GDAL or PROJ and want to double-check the transformation on a few sample points before running it on a 50 GB file, pasting the same proj4 strings into the browser converter is the fastest sanity check available.

Step-by-Step Workflow in gis.tools

1. Open the Proj4 Coordinate Converter in your browser.
2. Paste the source proj4 string into the "From" box. If you don't know it, inspect the source file with the CRS Metadata Inspector.
3. Paste the target proj4 string into the "To" box.
4. Either type coordinates into the input field or drop a GeoJSON, CSV, or WKT file.
5. (Optional) Adjust output precision and decimal format.
6. Click Convert. Transformed coordinates appear next to the inputs and a preview map shows before/after.
7. Export as GeoJSON, CSV, or WKT. For EPSG-identified targets, consider using the EPSG Reprojector & Coordinate Converter for a friendlier code-based interface.

Worked Example

A geologist in Iceland has a legacy drillhole dataset with coordinates in Reykjavík 1900 — an old local datum predating WGS84. The proj4 string is +proj=lcc +lat_1=64.25 +lat_2=65.75 +lat_0=65 +lon_0=-18 +x_0=500000 +y_0=500000 +ellps=intl +towgs84=-28,199,5,0,0,0,0 +units=m +no_defs. He needs the points in ISN93 (Iceland's modern datum) for integration with the national geology database: +proj=lcc +lat_1=64.25 +lat_2=65.75 +lat_0=65 +lon_0=-19 +x_0=500000 +y_0=500000 +ellps=GRS80 +towgs84=0,0,0 +units=m +no_defs. He pastes both strings into the Proj4 converter, drops the CSV of 1,247 drillholes, and in one second has a new CSV ready for upload. The Helmert shift and the change in central meridian are applied correctly, and the tool reports the maximum per-point delta (about 85 meters — the expected datum offset for Reykjavík 1900 → ISN93).

Common Pitfalls and Gotchas

• Missing +towgs84: Without datum shift parameters the transformation silently assumes datums are identical, producing meter-scale errors.
• Axis order confusion: Some proj4 strings imply (lat, lon) while GeoJSON expects (lon, lat). The converter follows GeoJSON convention but always verify on the map preview.
• Unit mismatch: +units=us-ft and +units=ft differ by 2 ppm — enough to matter at state-plane scales. Check the units parameter carefully.
• Deprecated parameters: Old proj4 strings may use +datum= shortcuts that proj4js handles slightly differently from PROJ 9; prefer explicit +ellps= and +towgs84= for reproducibility.
• Grid shift files not supported: Browser-based proj4js can't load external NTv2 or NADCON grids. For high-precision datum shifts use PROJ on the command line.
• Copy-paste whitespace: A stray line break inside a proj4 string will confuse the parser. Keep it on one line.
• Wrong spheroid: Mixing up Bessel, Clarke 1866, International 1924, and GRS80 ellipsoids leads to subtle but persistent shifts.
• Cylindrical singularities: Transverse Mercator is well-behaved only near its central meridian; far away it becomes unstable.

Tips for Best Results

• Start from a known-good proj4 string from epsg.io or the spatialreference.org archive when possible.
• When writing your own string, include +no_defs to suppress defaults that might surprise you.
• Specify +units= explicitly — don't rely on the projection's default.
• Verify on the map preview after every conversion, especially for the first few points of a batch.
• If accuracy is critical, compare the browser result against PROJ or GDAL on a small sample.
• Pair with the Distance Calculator to confirm that a round-trip transformation preserves distances.
• When sharing a proj4 string with a colleague, include the source (EPSG catalog, epsg.io URL, or internal document) so they can trace its provenance.

Comparison with Other GIS Approaches

Compared to cs2cs on the command line, QGIS's custom CRS dialog, or PostGIS ST_Transform, a browser proj4 converter offers instant startup and zero install. It is arguably the fastest way to try a few proj4 strings interactively. The desktop tools win on throughput (they can stream gigabytes), on grid-based datum shifts (they load NTv2 files), and on niche projections not yet supported in proj4js. For the 95% case — a custom local grid or a one-off transformation — the browser tool is the quickest path to a correct answer.

Performance Considerations

Each conversion is a handful of floating-point operations per coordinate. Throughput is tens of thousands of points per second on modern hardware. Files of a few hundred megabytes work fine; larger than that, and you will want a streaming command-line tool.

Data Privacy and Browser-Based Processing

Like all gis.tools converters, the proj4 tool runs 100% client-side. No coordinates, proj4 strings, or files are uploaded, logged, or shared. This is particularly valuable for proprietary engineering coordinates, confidential survey control, or unreleased geological data — the kind of information that should never cross a corporate firewall.

Related GIS Concepts

• WKT2: the modern machine-readable alternative to proj4 strings, more verbose but better at capturing datum provenance.
• PROJJSON: a JSON-serialized form of WKT2 introduced in PROJ 6.
• EPSG catalog: the published registry of well-known projections; every EPSG code can be converted to a proj4 string.
• Helmert transformation: the 7-parameter linear datum shift expressed by +towgs84.
• NTv2 grid shift: a higher-accuracy replacement for Helmert, stored as a binary grid of offsets.

Frequently Asked Questions

What is a proj4 string?

A compact text format describing a coordinate reference system, consisting of +key=value pairs such as +proj=utm +zone=33 +datum=WGS84 +units=m.

How do I get the proj4 string for a CRS?

Look it up on epsg.io, copy it from a .prj file, or use the CRS Metadata Inspector to extract it from a GeoJSON or shapefile.

Is proj4js accurate?

For the vast majority of projections, yes — sub-meter accuracy for most codes. For high-precision geodetic work requiring grid-based datum shifts, use PROJ 9 directly.

Can I chain multiple transformations?

Yes — reproject from A to B, download, then reproject from B to C. For most practical workflows, a single A → B step is sufficient.

What's the difference between this and the EPSG Reprojector?

The EPSG Reprojector & Coordinate Converter uses human-friendly EPSG codes for common systems. The Proj4 converter accepts arbitrary proj4 strings for custom or obscure projections.

Related Tools on gis.tools

• EPSG Reprojector & Coordinate Converter
• Lat/Lon ↔ UTM Converter
• CRS Metadata Inspector
• Coordinate Format Converter
• Datum Shift Visualizer
• Distance Calculator
• Area Calculator
• GeoJSON Validator & Fixer