WKT to GeoJSON

What this tool does

It reads each non-empty line as one WKT geometry and builds GeoJSON from it. POINT, LINESTRING, POLYGON, their MULTI forms and GEOMETRYCOLLECTION are all understood, with Z/M/ZM type suffixes accepted and an SRID=…; prefix stripped.

The intent it closes: "my query returned ST_AsText() output and I need to see it on a map." Paste the column, get a FeatureCollection, then open it in the viewer — which picks up whatever the last tool produced, so no copy-paste in between.

How this tool works

Line by line, with a tolerant parser.

1. Split and clean

The input is split on newlines. Blank lines and lines starting with # are ignored, so you can paste a query result with comments in it. A leading SRID=4326; (the EWKT form PostGIS emits) is removed before parsing — the coordinates are assumed to already be in the CRS your consumer expects.

2. Parse each geometry

The type name is read, then the coordinate list is split on nesting depth so commas inside inner parentheses are handled correctly. Each position takes the first two numbers, so POINT Z (30 10 5) parses as a 2D point rather than failing. A line that does not parse is counted and reported in the status bar instead of aborting the whole conversion.

3. Wrap the result

By default every geometry becomes a Feature with empty properties inside one FeatureCollection — the shape almost every map library wants. The other two options give you a GeometryCollection, or the bare geometry itself when there is exactly one.

Options

Wrap as

FeatureCollection is the safe default: Leaflet, Mapbox GL, OpenLayers and the tools on this site all accept it directly. GeometryCollection is more compact but has no place for properties. Bare geometry emits just the geometry when a single line was given — handy for pasting into a geometry field.

Indent

Two or four spaces for something readable, or minified when the output is going into a request body or an attribute.

Example

Input:

SRID=4326;POINT(-122.42 37.77)
LINESTRING(0 0, 1 1, 2 1)

Output:

{
  "type": "FeatureCollection",
  "features": [
    { "type": "Feature", "properties": {}, "geometry": { "type": "Point", "coordinates": [-122.42, 37.77] } },
    { "type": "Feature", "properties": {}, "geometry": { "type": "LineString", "coordinates": [[0, 0], [1, 1], [2, 1]] } }
  ]
}

The SRID=4326; prefix was stripped and the two lines became two features. Properties are empty — WKT carries none; if you have an attribute table, convert with GeoJSON to WKT in CSV mode instead so the round trip keeps them.

Tips & common pitfalls

• Coordinates are taken as longitude, latitude. That matches both WKT and GeoJSON. If your source is a system that emits lat/lon (some Java stacks do), the points will land in the wrong hemisphere and you will need to swap them upstream.
• Only EPSG:4326 makes sense for GeoJSON. RFC 7946 fixes the CRS at WGS 84. If your WKT holds projected metres, run the result through reproject to get degrees.
• Z and M values are dropped. The parser keeps the first two ordinates, so 3D and measured geometries come through flat.
• A whole CSV column works. Paste just the geometry column; other columns on the same line would be treated as part of the WKT and reported as unparseable.

FAQ

Does it accept EWKT?

Yes. A leading SRID=…; is stripped and the geometry parsed as normal. The SRID itself is not recorded — GeoJSON has no CRS member in RFC 7946.

What if one line is malformed?

It is skipped and counted, and the status bar tells you how many lines failed. The geometries that did parse are still converted, so one bad row does not lose the whole batch.

Can it read a GEOMETRYCOLLECTION?

Yes — it becomes a GeoJSON GeometryCollection geometry, with its members parsed recursively.

Is anything uploaded?

No. Parsing and serialising both run in your browser.