WKT Viewer & WKT to GeoJSON

Why WKT ends up on your clipboard

Well-Known Text is what spatial databases hand back when you ask them for a geometry in a readable form: ST_AsText() in PostGIS, SDO_UTIL.TO_WKTGEOMETRY() in Oracle, .STAsText() in SQL Server. It is precise and portable, but completely unreadable to a human — a polygon of a city block is a hundred numbers in a row. Pasting it here answers the only question you usually have: is this shape where I think it is?

What this viewer accepts

One geometry per line, so you can paste a whole column of query results and see every row at once. A leading SRID=4326; is stripped automatically, and Z or M dimension markers are tolerated (the extra ordinates are kept in the coordinate arrays). Coordinates are read as longitude then latitude, which is the WKT convention and the opposite of how most people say it out loud.

• POINT(90.41 23.81)
• LINESTRING(90.4 23.8, 90.42 23.82)
• POLYGON((90.4 23.8, 90.42 23.8, 90.42 23.82, 90.4 23.8))
• SRID=4326;MULTIPOINT((90.4 23.8),(90.41 23.81))

If nothing appears on the map

The usual cause is a projected coordinate system. If your numbers look like 512340 2601880 rather than 90.41 23.81, the geometry is in UTM or a national grid, not WGS84 degrees — the viewer will plot it far off the map or reject it. Reproject in the database first with ST_Transform(geom, 4326), or run the numbers through the coordinate converter. The second most common cause is axis order: some systems emit latitude first, which puts Dhaka in the Indian Ocean.

Getting from WKT to something you can share

GeoJSON is the practical destination: every web mapping library reads it, it survives copy and paste, and it round-trips through the other tools here. Download the GeoJSON and you can convert it to KML for Google Earth, flatten the attributes to CSV, or simplify it before putting it on a web map.