Skip to content

WKT to GeoJSON Converter

Convert Well-Known Text geometries to GeoJSON format for web mapping and visualization.

Skip to the tool

WKT usually arrives pasted out of a database client, and the dialects vary more than the specification suggests.

This parser reads all seven geometry types, the optional Z, M and ZM dimension flags, EMPTY geometries and scientific notation. An SRID=4326; prefix is stripped. Any other SRID is refused with a message, because GeoJSON positions are WGS 84 by definition and a Web Mercator coordinate pasted in unchanged lands in the wrong hemisphere.

A measure value in an M geometry is read and discarded, since GeoJSON has nowhere to put it. Anything the parser cannot read comes back with the character position and what it expected there.

Converting WKT to GeoJSON

This tool parses Well-Known Text (WKT) geometry strings and converts them to GeoJSON format. Paste a WKT string and get a properly structured GeoJSON Feature that you can visualize on the map, copy, or download.

WKTPOINT (-73.9857 40.7484)

The tool supports all standard WKT geometry types.

Supported WKT Types

  • POINT → GeoJSON Point
  • LINESTRING → GeoJSON LineString
  • POLYGON → GeoJSON Polygon
  • MULTIPOINT → GeoJSON MultiPoint
  • MULTILINESTRING → GeoJSON MultiLineString
  • MULTIPOLYGON → GeoJSON MultiPolygon
  • GEOMETRYCOLLECTION → GeoJSON GeometryCollection

Where WKT Comes From

WKT is the standard text output format for spatial databases. You will commonly encounter WKT when:

  • Querying PostGIS with ST_AsText(geom):
SQLSELECT name, ST_AsText(geom) FROM locations;
-- Returns: POINT (-73.9857 40.7484)
  • Exporting geometries from Oracle Spatial or SQL Server
  • Reading spatial columns in data analysis tools
  • Debugging spatial functions that return geometry as text

To convert in the other direction, use the GeoJSON to WKT converter.

A Central Park Polygon in WKT

Paste this WKT polygon representing a simplified boundary of Central Park in Manhattan. The converter produces a GeoJSON Feature:

WKTPOLYGON ((-73.9812 40.7681, -73.9580 40.8006, -73.9498 40.7969, -73.9730 40.7644, -73.9812 40.7681))

The resulting GeoJSON output:

GeoJSON{
  "type": "Polygon",
  "coordinates": [[
    [-73.9812, 40.7681],
    [-73.9580, 40.8006],
    [-73.9498, 40.7969],
    [-73.9730, 40.7644],
    [-73.9812, 40.7681]
  ]]
}

The output is a bare geometry, because WKT carries no properties for a Feature to hold. Wrap it yourself when you need one: a Feature is an object with type, geometry and properties members.

Dialect Quirks the Parser Handles

The parser walks the string with a cursor, which is what lets it accept the variations real databases emit:

  • Dimension flags. POINT Z (1 2 3) keeps the third ordinate as elevation. POINT M (1 2 5) drops the measure value, because GeoJSON has nowhere to store one. POINT ZM (1 2 3 5) keeps the elevation and drops the measure.
  • Both MULTIPOINT spellings. MULTIPOINT (1 2, 3 4) and MULTIPOINT ((1 2), (3 4)) are equally valid and both parse.
  • EMPTY geometries. POLYGON EMPTY becomes a polygon with an empty coordinates array.
  • Scientific notation. 1.5e2 is read as 150.
  • EWKT prefixes. SRID=4326; is stripped. Any other SRID is refused, because reading projected coordinates as if they were degrees puts the geometry somewhere else entirely, with nothing to show for it.

Anything else fails with the character position and what the parser expected there, so a missing bracket in a long MULTIPOLYGON is findable. For moving spatial data between PostGIS and GeoJSON in bulk, see the PostGIS guide.