MySQL 8.0+ · lat/long order · no sign-up

Address in.
MySQL POINT out.

pointkit geocodes a plain address and hands back a MySQL 8 POINT literal in SRID 4326's lat/long axis order — the reverse of Postgres, WKT, and GeoJSON, and the single most common way spatial inserts go quietly wrong.

Also available: MariaDB / MySQL 5.7 · Postgres/PostGIS · WKT · GeoJSON
MySQL 8.0+ · ST_GeomFromText
{{ heroResultText }}
MySQL 8.0+ reads SRID 4326 as lat/long, the reverse of standard WKT, so the point is written latitude first. On MariaDB or MySQL 5.7, use the homepage converter's “MariaDB / MySQL 5.7” option instead.
INSERT INTO places (name, geom) VALUES ('example', {{ heroResultText }});
{{ heroWarningText }}

The one convention MySQL got "backwards"

Almost everything in the spatial world — WKT, GeoJSON, PostGIS — orders coordinates as (longitude, latitude). Since 8.0, MySQL's SRID 4326 follows the strict EPSG definition instead and orders them as (latitude, longitude). If you're coming from Postgres, or copying a longitude/latitude pair straight from a mapping API, it's exactly backwards from what you'd expect.

Get it wrong anywhere longitude is within ±90° — Europe, Africa, most of Asia, South America, eastern North America — and MySQL accepts the geometry without complaint: the point just lands in the wrong place, with nothing in the logs to explain why. Elsewhere you get an out-of-range latitude error instead. pointkit geocodes the address and outputs the literal in MySQL's expected order automatically, so this one never bites.

Worked example: an address into MySQL 8

1600 Amphitheatre Parkway, Mountain View, CA is at latitude 37.4224, longitude -122.0842. MySQL 8.0+ wants latitude first for SRID 4326.

Create the table

Declaring SRID 4326 on the column makes MySQL reject points in any other reference system, including the SRID 0 points the bare POINT(x, y) constructor makes.

CREATE TABLE places (
  id   INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(255),
  geom POINT NOT NULL SRID 4326
);

Insert the point

INSERT INTO places (name, geom)
VALUES ('Googleplex', ST_GeomFromText('POINT(37.4224 -122.0842)', 4326));

Check the order

ST_Latitude and ST_Longitude read the coordinates by name, so they're right whichever way round the WKT was written.

SELECT name, ST_Latitude(geom) AS lat, ST_Longitude(geom) AS lng FROM places;

Fix rows that went in swapped

A swapped US address like this one fails loudly, because -122 isn't a valid latitude. Wherever longitude is within ±90° (Europe, Africa, most of Asia, South America and eastern North America) both orders are valid and the swapped point goes in silently. ST_SwapXY swaps it back; run it only on rows you know are wrong.

UPDATE places
SET geom = ST_SwapXY(geom)
WHERE id = 42;  -- a row you've checked is swapped

On MariaDB or MySQL 5.7, write the same point longitude first, POINT(-122.0842 37.4224), and read it back with ST_X (longitude) and ST_Y (latitude).

Axis order by database

TargetOrderExample (37.4224, -122.0842)
MySQL 8.0+, SRID 4326lat, lngST_GeomFromText('POINT(37.4224 -122.0842)', 4326)
MariaDB, MySQL 5.7lng, latST_GeomFromText('POINT(-122.0842 37.4224)', 4326)
Postgres / PostGISlng, latST_GeomFromText('POINT(-122.0842 37.4224)', 4326)
WKTlng, latPOINT(-122.0842 37.4224)
GeoJSONlng, lat{"type":"Point","coordinates":[-122.0842,37.4224]}
Leaflet, Google Mapslat, lngL.marker([37.4224, -122.0842])

MySQL FAQ

Why is MySQL's axis order the reverse of Postgres/WKT?

Since 8.0, MySQL's SRID 4326 follows the strict EPSG:4326 definition literally: (latitude, longitude). MariaDB and MySQL 5.7 don't, and read longitude first. Postgres/PostGIS, WKT, and GeoJSON follow the more common (longitude, latitude) convention instead. Neither is "wrong" — mixing them up is just the most common way spatial inserts fail silently.

Do I use ST_GeomFromText or POINT() in MySQL?

Use ST_GeomFromText('POINT(lat lng)', 4326) for geographic coordinates. The shorthand POINT(x, y) constructor makes a point with SRID 0, which a column declared SRID 4326 rejects, and treats x as longitude. pointkit outputs the whole ST_GeomFromText(..., 4326) expression, ready to paste into an INSERT.

Does this work with MariaDB, not just MySQL?

Yes, but it needs a different literal. MariaDB, like MySQL 5.7, ignores SRID 4326's official axis order and always reads longitude first, so a MySQL 8 literal would land with its coordinates swapped. Pick “MariaDB / MySQL 5.7” on the homepage converter for longitude-first output.

Can I convert a whole table of addresses at once?

Yes — export the addresses as a CSV and use pointkit's batch converter, which appends a POINT column to the file so you can load it back in with LOAD DATA INFILE or an ORM import.