GeoJSON to WKT

What this tool does

It walks your document, takes each feature's geometry, and writes it as well-known text: POINT(30 10), LINESTRING(…), POLYGON((…)), and the MULTI variants, plus GEOMETRYCOLLECTION for nested geometries. Coordinate order is longitude then latitude — the same order GeoJSON uses, and the order WKT expects.

The intent it closes: "I need this geometry in a SQL statement." WKT is what ST_GeomFromText takes, what a BigQuery GEOGRAPHY column accepts as text, and what most desktop GIS will paste into a geometry field. It is also far more compact than GeoJSON when you only need the shape and not the properties.

How this tool works

One click, three steps, all in the browser.

1. Parse and collect geometries

The input is parsed as JSON and normalised: a FeatureCollection yields its features, a single Feature yields one, and a bare geometry is wrapped so it can be handled the same way. Features with a null geometry are skipped rather than emitting an empty string.

2. Round, if you asked for it

With Round to set to -1 (the default) coordinates are written exactly as they appear. Set it to a digit count and every ordinate is rounded first — six decimals is about 11 cm at the equator, which is plenty for most mapping and cuts the text size noticeably.

3. Write WKT

Each geometry becomes a WKT string. In one WKT per line mode you get a plain list you can paste into a column. In GEOMETRYCOLLECTION mode all of them are wrapped in a single geometry, which is what you want when the whole document has to be one value. In CSV mode the first column is wkt and the rest are the union of all feature properties, so nothing is lost.

Options

Output

One WKT per line is the useful default for building an INSERT or pasting into a spreadsheet column. Single GEOMETRYCOLLECTION produces exactly one geometry — note that many spatial functions handle collections awkwardly, so use it only when the consumer asks for it. CSV with properties keeps the attribute table alongside the geometry, which is the shape most bulk loaders want.

Round to

Decimal places for every ordinate, or -1 to leave the numbers untouched. Rounding here happens before the WKT is written, so it also shrinks the output — useful when a 12-decimal export is being pasted into a query.

Example

Input:

{
  "type": "FeatureCollection",
  "features": [
    { "type": "Feature", "properties": { "name": "HQ" },
      "geometry": { "type": "Point", "coordinates": [-122.42, 37.77] } }
  ]
}

Output (one per line):

POINT(-122.42 37.77)

In CSV mode the same input gives wkt,name then POINT(-122.42 37.77),HQ — ready for a bulk load where the geometry column is parsed with ST_GeomFromText.

Tips & common pitfalls

• Longitude first. Both GeoJSON and WKT put X (longitude) before Y (latitude). If your database shows points in the ocean, the problem is almost always a swap somewhere else in the pipeline, not here.
• WKT carries no SRID. Plain WKT has no coordinate system. Wrap it as ST_GeomFromText('…', 4326), or use the EWKT form SRID=4326;POINT(…) that PostGIS accepts.
• Z values are dropped. The output is 2D. If you need POINT Z, keep the GeoJSON and let the database read the third ordinate from it instead.
• Very large polygons make very long lines. A single WKT string for a detailed coastline can run to megabytes. Round the coordinates, or simplify first.

FAQ

What is WKT?

Well-known text is the OGC's human-readable geometry format — POINT(30 10), POLYGON((30 10, 40 40, 20 40, 30 10)). It is the text form of the same geometries GeoJSON describes, and it is what spatial SQL functions parse.

Does it include the properties?

Only in CSV mode, where every property key across the document becomes a column. The other two modes emit geometry alone.

Can I convert back?

Yes — WKT to GeoJSON reads one geometry per line, including the SRID=…; prefix, and gives you a FeatureCollection.

Is my data uploaded?

No. The parse and the conversion both happen in your browser; the coordinates never leave the tab.