WKT Viewer & Converter

Paste WKT or GeoJSON and see the geometry drawn instantly — points, lines, polygons, and every MULTI* type. Read its bounding box and centroid, and convert WKT ⇄ GeoJSON with one click. Everything runs in your browser; nothing is uploaded.

It also decodes the hex a database shows for a spatial column — SQL Server geometry/geography (0xE6100000010C…), PostGIS EWKB and plain WKB, MySQL's SRID-prefixed format, SpatiaLite and GeoPackage blobs — to WKT, with the SRID and the detected format.

How to use the WKT viewer

Paste a geometry into the box on the left. The viewer auto-detects whether it is WKT (or PostGIS EWKT with a SRID=…; prefix) or GeoJSON, parses it, and draws it on the right — points as dots, lines as strokes, and polygons filled and outlined, with interior rings cut out as holes. Below the picture you get a stats line: the geometry type, vertex count, bounding box, and centroid. Use the Input format selector to force a format if auto-detection guesses wrong, and the Load example buttons to see a polygon, a line, a multipolygon, or a curved geometry rendered immediately.

Paste a hex value instead — 0x…, \x…, X'…' or bare hex digits, in any letter case, even broken over several lines — and the viewer decodes it as a database spatial value. A Decoded WKT box appears under the input with the format it was read as, the byte count and the SRID; Copy as WKT then copies that WKT. The Load database hex buttons fill in one sample value per format, taken from the desktop app's decoder tests. Two are derived: the WKB sample is the MySQL linestring without its SRID prefix, and the SQL Server geography sample is the SQL Server point with its two numbers in geography order.

The map is a simple fit-to-data planar projection with a light coordinate grid — it shows the shape and relative positions of your geometry, not a georeferenced street map. That keeps the tool fully self-contained: there are no tile servers and no map libraries, so nothing you paste ever leaves your browser.

What formats are supported

• WKT geometry types — POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, and GEOMETRYCOLLECTION. Optional Z/M ordinates are read and ignored for the 2-D drawing.
• EWKT SRID prefix — a leading SRID=4326; is parsed, shown in the stats line, and preserved when you copy back to WKT.
• GeoJSON — a bare geometry, a Feature, or a FeatureCollection (folded into a GEOMETRYCOLLECTION when converting to WKT).
• Curved WKT — CircularString, CompoundCurve, CurvePolygon, MultiCurve, and MultiSurface are detected and drawn approximated as straight segments between control points, with a heads-up note. For WKT text the tool does not re-fit true arcs.
• Spatial hex from a database — PostGIS EWKB and plain OGC/ISO WKB (little- or big-endian), MySQL's internal format (4-byte SRID + WKB), SQL Server geometry and geography, SpatiaLite blobs, and GeoPackage blobs. Curved WKB is drawn with its arcs linearized, and the decoded WKT keeps the curve.

Decode the hex your database shows for a spatial column

Most SQL clients do not print a geometry column as text. They print the stored bytes as hex, and each database stores geometry differently. Paste that value and the viewer works out which format it is, decodes it to WKT, shows the SRID, and draws the shape. The decoding is done by the Jam SQL Studio desktop app's spatial decoder module, compiled into one script for this page. The app decodes PostGIS, MySQL, SpatiaLite and GeoPackage values with that same code. SQL Server values reach the app already parsed by its SQL Server driver, not as hex; this page reads SQL Server hex with the module's byte reader, and handles geography hex with its own step that swaps each stored latitude/longitude pair first. Auto-detect tries the formats whose first bytes fit, in this order: GeoPackage (4750), SpatiaLite (00 … 7C … FE), WKB / EWKB (byte order 00 or 01), MySQL, then SQL Server, and keeps the first one that decodes to the last byte. Pick a format under Input format to decode as that format only.

SQL Server geometry and geography

• The SSMS results grid shows a geometry or geography column as hex that starts with the SRID: 0xE6100000010C… is SRID 4326 (E6100000), version 1, and a single point (0C). Copy the cell and paste it.
• geometry and geography use the same storage layout, except that geography writes each point latitude first. The bytes alone cannot say which type a value came from, so choose SQL Server geometry or SQL Server geography when you know the column type. Auto-detect reads a value as geometry when its SRID is 0, when its SRID is one geography does not allow, or when a point's first stored number is outside ±90, and as geography otherwise; the result line says which it chose. Geography accepts only the SRIDs listed in sys.spatial_reference_systems (393 on SQL Server 2025, all geographic systems such as 4326, 4269 and 4258), so a value in a projected SRID such as 3857 or 27700 always reads as geometry. A geometry column in SRID 4326 with longitudes within ±90 still reads as geography, so pick SQL Server geometry for those. Either way the WKT puts X (longitude) first.
• To get text from SQL Server itself: SELECT geom.STAsText() FROM dbo.Places; returns WKT (geom.AsTextZM() keeps Z and M), and geom.STAsBinary() returns plain WKB without the SRID, which this viewer reads with WKB / EWKB.
• SSMS shows at most 65,535 characters of a non-XML value in the results grid by default, so a large geometry copied from the grid is cut off. Raise Maximum Characters Retrieved under Tools → Options → Query Results → SQL Server → Results to Grid, or use STAsText().

To see a whole SQL Server spatial column on a map instead of one value at a time, see how to view SQL Server geometry and geography on a map.

PostgreSQL / PostGIS

• psql prints a geometry or geography column as EWKB hex: SELECT geom FROM places; returns values such as 0101000020E6100000DE02098A1F03354013F241CF661D4A40. Paste them as they are.
• SELECT ST_AsHEXEWKB(geom) returns the same EWKB hex as text. ST_AsEWKB(geom) and ST_AsBinary(geom) return bytea, which psql prints as \x0101…; paste that too. ST_AsBinary leaves out the SRID (plain WKB).
• For text, ST_AsText(geom) returns WKT and ST_AsEWKT(geom) returns SRID=4326;POINT(…), which this viewer also reads.

For whole PostGIS tables rather than single values, see the PostGIS viewer comparison.

MySQL

• MySQL stores a geometry as a 4-byte little-endian SRID followed by standard WKB. SELECT HEX(g) FROM places; returns that stored value, for example E61000000101000000DE02098A1F03354013F241CF661D4A40. The mysql command-line client (8.0.19 and later) prints binary columns as 0x… in interactive sessions (--binary-as-hex); that form works too.
• The stored WKB keeps X (longitude) first, even for SRID 4326. ST_AsBinary(g) and ST_AsText(g) return a 4326 value latitude first unless you pass 'axis-order=long-lat', so HEX(g) is the value to paste; for WKB from ST_AsBinary, use HEX(ST_AsBinary(g, 'axis-order=long-lat')).

SQLite: SpatiaLite and GeoPackage

• SpatiaLite: SELECT hex(geom) FROM places; returns the blob, which starts 0001E6100000 (start byte, little-endian, SRID 4326), has 7C after the stored bounding box, and ends with FE.
• GeoPackage: SELECT hex(geom) FROM places; (the geometry column is listed in gpkg_geometry_columns) returns a blob that starts 4750 (“GP”), then the version, flags, SRID, an optional envelope and standard WKB.
• In the sqlite3 shell, .mode quote prints blobs as X'0001…'; paste that form as it is.

Oracle SDO_GEOMETRY

SQL Developer and SQL*Plus show an SDO_GEOMETRY as constructor text such as MDSYS.SDO_GEOMETRY(2001, 4326, MDSYS.SDO_POINT_TYPE(21.0122, 52.2297, NULL), NULL, NULL). This viewer does not parse that text. Convert it in Oracle with SELECT SDO_UTIL.TO_WKTGEOMETRY(geom) FROM places; (or p.geom.GET_WKT()) and paste the WKT. The desktop app reads SDO_GEOMETRY columns from the result set directly.

Worked example: one point in seven encodings

Warsaw city centre, longitude 21.0122 and latitude 52.2297 in SRID 4326, as each database prints it. The values come from the desktop app's decoder test fixtures (the WKB row is the MySQL value without its SRID prefix, and the geography row is the SQL Server point with its two numbers in geography order). On 2026-09-23 each row matched what the database returns for this point: PostGIS 3.4 in psql, MySQL 8.0 HEX(), SQL Server 2025 for geometry::Point(21.0122, 52.2297, 4326) and geography::Point(52.2297, 21.0122, 4326), and SpatiaLite 5.1.0 (AsGPB() for the GeoPackage row). Paste any of them into the viewer above.

Byte by byte, the PostGIS value reads:

• 01 — byte order: little-endian
• 01000020 — geometry type 1 (Point) with the EWKB SRID flag 0x20000000
• E6100000 — SRID 0x10E6 = 4326
• DE02098A1F033540 — X = 21.0122 (longitude), an 8-byte little-endian double
• 13F241CF661D4A40 — Y = 52.2297 (latitude)

The SQL Server geography value is E6100000 (SRID 4326), 01 (version 1), 0C (valid, single point), then latitude 13F241CF661D4A40 and longitude DE02098A1F033540. The geometry value differs only in the order of those two numbers, which is why the two types cannot be told apart from the bytes.

Limits of the hex decoder

• Size: up to 5 MB of binary per value (10,485,760 hex digits), the same limit the desktop app applies when it decodes grid cells automatically. Larger values are rejected with a message.
• Geometry types: Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon and GeometryCollection, with Z and M. Curves: CircularString, CompoundCurve, CurvePolygon, MultiCurve and MultiSurface in WKB, EWKB and GeoPackage values, and root-level CircularString, CompoundCurve and CurvePolygon in SQL Server values. MySQL and SpatiaLite blobs have no curve types.
• Not decoded: PolyhedralSurface, TIN and Triangle; SQL Server FullGlobe and curves nested inside a collection; SpatiaLite compressed geometries and TinyPoint blobs; Oracle SDO_GEOMETRY text. Each gets an error message instead of a drawing.
• Cut-off values: a value that ends early is reported as truncated. Bytes after the end of a WKB, MySQL or SQL Server geometry are ignored with a note.
• Drawing: the SRID is shown but not used to reproject; the canvas is the same planar, fit-to-data preview as for WKT.

The hex decoder is one script, /js/tools/spatial-decode.js (about 50 KB, 15 KB compressed), served from jamsql.com. It makes no network requests, and the value you paste is not sent anywhere or saved. Like every jamsql.com page, this one also loads Umami analytics (which records the page view), the Google Ads tag (gtag.js) and /js/jam-events.js. The viewer's own analytics events carry format names and codes, never the pasted value:

• tool-wkt-viewer-parse with format (wkt, geojson or binary), once per page view;
• tool-wkt-viewer-decode with format and mode (auto or explicit), and tool-wkt-viewer-decode-error with format, reason and mode, each once per distinct outcome per page view;
• tool-wkt-viewer-load-sample with format, per Load database hex click;
• tool-wkt-viewer-copy with format (geojson or wkt), plus tool-wkt-viewer-copy-geojson or tool-wkt-viewer-copy-wkt, per copy button click;
• on the links: download_page_click and tool_product_click in the box beside the result, and tool-wkt-viewer-download-cta on Download Free.

WKT vs GeoJSON at a glance

• Coordinate order — both put longitude before latitude. WKT writes a point as x y (space-separated); GeoJSON writes [x, y]. This tool keeps the order intact through the round trip. (One wrinkle: SQL Server stores geography latitude-first in its own type — the Jam SQL Studio desktop app and this viewer's SQL Server geography input normalize that on decode, so the WKT they show and copy is standard longitude-latitude.)
• Where they show up — WKT is what relational databases speak (PostGIS ST_AsText, SQL Server .STAsText(), Oracle SDO_UTIL.TO_WKTGEOMETRY); GeoJSON is what web maps and JavaScript expect.
• Curves — WKT can express true arcs (CircularString); GeoJSON has no arc primitive, so this tool converts a curve to a plain line: through its control points for WKT text, or along the arc in short segments for decoded hex. That is why converting a curve to GeoJSON is inherently an approximation.

Frequently asked questions

What is WKT (Well-Known Text)?

Well-Known Text is a plain-text way to describe vector geometry — for example POINT (30 10), LINESTRING (30 10, 10 30, 40 40), or POLYGON ((35 10, 45 45, 15 40, 35 10)). It is defined by the OGC Simple Features standard and is understood by PostGIS, MySQL, SQL Server, Oracle Spatial, and SpatiaLite. Coordinates are written x y (longitude latitude for geographic data), and an optional SRID=4326; prefix names the coordinate system.

How do I convert WKT to GeoJSON (and back)?

Paste WKT into the viewer above and click Copy as GeoJSON — the tool parses the geometry and emits an equivalent GeoJSON object. Paste GeoJSON instead and click Copy as WKT to go the other way. The converter maps POINT/LINESTRING/POLYGON and all the MULTI* types plus GEOMETRYCOLLECTION to their GeoJSON equivalents, so the round trip preserves the shape. Everything runs in your browser.

Does this tool support MULTIPOLYGON and GEOMETRYCOLLECTION?

Yes. It parses POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, and GEOMETRYCOLLECTION, in both WKT and GeoJSON, and draws every part on the same canvas. Polygon holes (interior rings) are rendered correctly with an even-odd fill, and a GEOMETRYCOLLECTION can mix points, lines, and polygons in one value.

What does the SRID=4326; prefix mean?

SRID is a Spatial Reference System Identifier — a numeric code for the coordinate system the numbers are expressed in. SRID 4326 is WGS 84, the longitude/latitude system used by GPS. The SRID=4326;POINT (…) form is Extended WKT (EWKT), how PostGIS labels a geometry's coordinate system. This viewer reads and preserves the SRID prefix; it draws everything with a simple fit-to-data planar projection, so the picture shows the shape rather than a georeferenced map.

Are curved geometries like CircularString supported?

Yes. In WKT text, the viewer detects CircularString, CompoundCurve, CurvePolygon, MultiCurve, and MultiSurface and draws them as straight segments between their control points, with a note that the arcs are approximated; for WKT it does not re-fit true arcs. Curved hex (WKB, EWKB, GeoPackage or SQL Server values) goes through the desktop app's curve linearizer instead, so the drawing follows the true arc in short straight segments while the decoded WKT and Copy as WKT keep the exact curve. The Jam SQL Studio desktop app draws curves the same way on a real map, on PostgreSQL, Oracle, SQLite, and SQL Server (MySQL has no curve types).

Is my geometry data uploaded anywhere?

No. The viewer is plain JavaScript running entirely in your browser — parsing, drawing, and conversion all happen locally, with no tile servers and no map libraries loaded. The page makes no network requests with your data; you can disconnect from the internet after it loads and it keeps working.

How do I convert SQL Server geography hex to WKT?

Copy the 0x… value from the SSMS results grid and paste it into the viewer; it shows the WKT, the SRID and a drawing. SQL Server geometry and geography share one byte layout, with latitude stored first for geography, so the result line says which type the value was read as and Input format lets you pick the other one. Inside SQL Server, SELECT geog.STAsText() returns the same geometry as WKT (without Z and M values).

What is the difference between WKB and EWKB?

WKB, from the OGC Simple Features standard, stores a byte-order flag, a geometry type code and the coordinates, with no SRID. PostGIS EWKB sets flag bits in the type code and writes the SRID after it, so 0101000020E6100000… is a Point with the SRID flag and SRID 4326. The viewer reads both, in either byte order, and says which one it found.

Why does MySQL geometry hex start with E6100000?

Only a value in SRID 4326 does. MySQL stores a geometry as a 4-byte little-endian SRID followed by standard WKB, and E6100000 is 4326 in little-endian byte order; a value with SRID 0 starts with 00000000 and one in SRID 3857 with 110F0000. SELECT HEX(g) returns that stored value, while ST_AsBinary(g) returns only the WKB, latitude first for SRID 4326 unless you add 'axis-order=long-lat'. The viewer reads the SRID from the prefix and decodes the WKB after it.

Want this on your live database?

Jam SQL Studio is a free desktop SQL client for PostgreSQL/PostGIS, MySQL, SQL Server, Oracle, and SQLite. It decodes geometry and geography columns straight from the connection and renders them as interactive maps — in the results grid, a peek popover, a Query Editor Map view, a Table Explorer map pane, and a dedicated Spatial Explorer workspace. An optional street basemap is on by default and can be switched off for a fully offline planar view, and curved geometry is linearized for display while your copied WKT stays exactly curved.

Free for personal use • No account required • Mac, Windows, Linux

More free SQL tools