Latitude vs Longitude: Which Comes First?

There is no universal rule that latitude or longitude must always come first. In ordinary geographic notation, coordinates are often written as latitude followed by longitude. In many GIS formats and programming interfaces, however, coordinates follow an x-y convention, which means longitude comes before latitude. GeoJSON, for example, explicitly requires longitude first. Formal EPSG:4326 axis order goes the other way: latitude first, then longitude.

The safest rule is therefore not to memorise one order. It is to know what the format, coordinate reference system, API, or application expects.

Latitude and longitude describe different directions

Latitude describes how far north or south a location lies relative to the equator. The equator is 0°, the North Pole is +90°, and the South Pole is −90° when signed decimal degrees are used.

Longitude describes position east or west relative to the prime meridian. In the common signed-degree convention, longitude ranges from −180° to +180°.

This makes a useful mental model possible:

• latitude → north/south → y-like direction

• longitude → east/west → x-like direction

That x-y relationship is one of the main reasons coordinate order becomes confusing. People frequently say “latitude and longitude”, but many spatial data structures are built around the mathematical convention of specifying x before y. For geographic coordinates, x normally corresponds to longitude and y to latitude.

As a result, the same location can legitimately be written in different orders depending on the context.

So which order should you use?

It depends on what is consuming the coordinates.

• Context: Human-readable “latitude, longitude” notation; Typical or required order: Latitude, longitude

• Context: Formal EPSG:4326 axis order; Typical or required order: Latitude, longitude

• Context: OGC CRS84; Typical or required order: Longitude, latitude

• Context: GeoJSON positions; Typical or required order: Longitude, latitude

• Context: Cartesian GIS convention (x, y) for geographic coordinates; Typical or required order: Longitude, latitude

• Context: PostGIS ST_MakePoint(x, y) with geodetic coordinates; Typical or required order: Longitude, latitude

• Context: A specific website, API, CSV schema, or software interface; Typical or required order: Check its documentation

The important word in that table is context.

GeoJSON is unambiguous. RFC 7946 defines a position as an array whose first two elements are longitude and latitude, in that order. A GeoJSON point at an illustrative longitude of 12° east and latitude of 4° north would therefore be written as:

{
  "type": "Point",
  "coordinates": [12, 4]
}

Writing [4, 12] would not mean the same thing. GeoJSON would interpret the first number as longitude and the second as latitude.

PostGIS exposes the same x-y convention directly. Its documentation for ST_MakePoint(x, y) states that for geodetic coordinates, x is longitude and y is latitude. The corresponding illustrative expression would therefore be:

ST_MakePoint(12, 4)

not ST_MakePoint(4, 12).

This does not contradict the habit of saying “latitude and longitude”. It simply means that natural-language ordering and coordinate-array ordering are not always the same thing.

EPSG:4326 makes the question more complicated

EPSG:4326 is where simplistic rules such as “GIS always uses longitude first” begin to break down.

The formal axis order of EPSG:4326 is latitude first, longitude second. Standards and software that honour the CRS's defined axis order therefore treat that distinction as meaningful.

At the same time, many software-oriented geographic formats use longitude first. GeoJSON does so by using the WGS 84 longitude-latitude convention associated with OGC CRS84, rather than adopting the formal latitude-longitude axis ordering of EPSG:4326.

CRS84 and EPSG:4326 are consequently very closely related geographically, but their axis order differs:

EPSG:4326 → latitude, longitude

OGC CRS84 → longitude, latitude

This distinction is easy to miss because developers and GIS users sometimes use phrases such as “WGS 84 coordinates”, “4326”, and “latitude/longitude” rather loosely when discussing geographic data. At the point where coordinates are actually serialised or passed between systems, however, the ordering convention matters.

It is also one example of a broader issue: coordinates cannot be interpreted correctly without knowing the reference system and conventions attached to them. If that distinction is unfamiliar, EPSG:4326 vs EPSG:3857: WGS 84 and Web Mercator Explained explains how the same geographic location can be represented very differently by a geographic and a projected CRS.

Why reversed coordinates can be difficult to detect

Sometimes a latitude-longitude reversal fails spectacularly. Sometimes it produces a perfectly valid point in the wrong place.

Suppose the intended coordinates are:

latitude = 4° longitude = 12°

If an application expects longitude first, [12, 4] represents the intended location. If you supply [4, 12] instead, both numbers are still individually valid as longitude and latitude values. The software may therefore accept the coordinates without an error and place the point somewhere completely different.

This is one reason reversed coordinates can survive surprisingly far through a workflow: syntactic validity does not imply geographic correctness.

Other reversals are easier to catch. A latitude cannot normally exceed 90° north or south, so if a supposed latitude contains a value such as 120, coordinate order is an obvious suspect. Longitude, on the other hand, can legitimately have a magnitude above 90°.

Range checking is therefore useful, but it cannot detect every reversal. If both values fall between −90 and +90, either order may appear numerically plausible.

If you are diagnosing an existing dataset rather than simply trying to understand the convention, How Can You Tell Whether Latitude and Longitude Were Reversed? goes further into range checks, expected extents, known control locations and other clues.

X and Y do not mean latitude and longitude in that order

Another common source of mistakes is assuming that x means latitude because latitude was written first in a form or spreadsheet.

In a conventional Cartesian plane, x describes the horizontal direction and y the vertical direction. When that model is applied to geographic longitude and latitude, longitude behaves like x because it varies east-west, while latitude behaves like y because it varies north-south.

So:

x → longitude y → latitude

This is why coordinates in geometry libraries, spatial databases, GeoJSON-like structures, and other technical contexts so often appear as longitude followed by latitude.

But even this should not become an absolute rule. A coordinate reference system defines the axes that give its coordinates meaning, and those axes do not universally have to be easting then northing or longitude then latitude. The CRS definition, data format and software contract remain authoritative.

That becomes especially important with projected data. Values described as x and y may represent eastings and northings rather than longitude and latitude at all. The distinction deserves a separate explanation, so X and Y vs Latitude and Longitude looks more broadly at geographic coordinates, Cartesian notation and projected coordinate systems.

How to avoid latitude-longitude mistakes

The most reliable workflows remove ambiguity rather than relying on memory.

When coordinates appear in a table, prefer explicit field names such as latitude and longitude over ambiguous labels such as coordinate_1 and coordinate_2. When a format uses arrays, confirm its specification before constructing or transforming them. When an API accepts an object such as {lat, lon} or {lat, lng}, follow those named fields rather than assuming that the API follows an x-y convention.

For bare coordinate pairs, several checks are useful:

1. Check the format or API documentation. A documented ordering rule is stronger evidence than convention.

2. Check the CRS and its axis definition. “WGS 84” alone may not tell you how a particular serialisation expects its coordinate array.

3. Inspect the value ranges. A latitude outside −90° to +90° is an immediate warning.

4. Test a known location. If possible, plot or inspect one coordinate whose approximate position you already know.

5. Preserve meaningful column names and metadata. Coordinate order becomes much harder to confuse when the schema explains itself.

For automated pipelines, validation should happen before a large dataset is accepted simply because every row contains two valid numbers. A pair of plausible numbers can still describe the wrong place.

The signs of the numbers themselves can provide useful context too. A negative value is not inherently suspicious: signed decimal degrees use negative longitude west of the prime meridian and negative latitude south of the equator. If that convention is unfamiliar, the explanation of why geographic coordinates can be negative is a useful companion to the ordering problem.

What about bounding boxes?

Coordinate order matters for bounding boxes too, and this is another place where memorised rules can fail.

A common longitude-latitude bounding box representation is:

[min_longitude, min_latitude, max_longitude, max_latitude]

This follows the same x-y logic as many geographic APIs: west/east values first, south/north values second. OGC API standards commonly use CRS84 longitude-latitude ordering in their default geographic bounding-box conventions.

But not every protocol, CRS, or API necessarily follows that order. A bounding box should therefore be interpreted according to the CRS and interface that define it, rather than by assuming that every four-number geographic extent means west, south, east, north.

The problem is the same as with points, only multiplied across two corners.

“Lat-long” is a phrase, not a file format

Perhaps the simplest way to remember all of this is to separate how people describe coordinates from how software encodes them.

“Latitude and longitude” is an intuitive way to describe a geographic position. It does not establish the serialisation order of every system that stores that position.

If you are writing a report or telling another person a location, latitude followed by longitude may be perfectly natural. If you are building GeoJSON, longitude comes first. If you are creating a geodetic point with PostGIS, x is longitude and y is latitude. If a standards-based system is explicitly following EPSG:4326 axis order, latitude comes first.

None of these conventions becomes universally correct simply because it appears frequently.

The real question is therefore not “Does latitude or longitude come first?”

It is “What coordinate order does this particular representation require?”

Once the format, CRS and interface are explicit, the ambiguity disappears.

References

1. IETF RFC 7946 — The GeoJSON Format. Specifies longitude followed by latitude for GeoJSON positions.

2. EPSG Registry — WGS 84 (EPSG:4326). Defines EPSG:4326 as a geographic 2D CRS whose formal axis order is latitude, longitude.

3. PROJ — Frequently Asked Questions. Explains CRS axis-order differences and the distinction between formal CRS axes and software conventions.

4. OGC Web Map Service 1.3.0. Defines CRS:84 as WGS 84 longitude-latitude and contrasts it with the latitude-longitude axis order of EPSG:4326.

5. PostGIS — Geometry Accessors Reference. Documents functions such as ST_X and ST_Y for accessing x and y coordinates from geometries.