X and Y vs Latitude and Longitude

X and y are generic coordinate-axis labels. Longitude and latitude are specific geographic coordinates. In many software and data formats, x corresponds to longitude and y to latitude, but that relationship is a convention of the coordinate space being used rather than a universal definition.

An x-y pair might contain geographic degrees. It might instead contain projected eastings and northings in metres, local engineering coordinates, image pixels or screen positions. The values only become geographically meaningful when their coordinate system, units and axis conventions are known.

What x and y actually tell you

In a conventional Cartesian plane, x identifies position along one axis and y along another. We usually draw x horizontally and y vertically, which encourages the shorthand:

x -> horizontal
y -> vertical

That shorthand is useful, but it says nothing by itself about the Earth.

A GIS dataset with values around 500000, 4500000 may store an easting and northing in a projected CRS. An engineering drawing might use an arbitrary site origin. A raster image might use pixel coordinates measured from the upper-left corner, with y increasing downwards. A browser map library can expose screen x/y values that change whenever the map is panned or zoomed.

All of these are legitimate x-y coordinates, yet none should be interpreted as longitude and latitude merely because the fields are named x and y.

Longitude and latitude describe position on a geographic reference system

Longitude measures angular position east or west of a prime meridian. Latitude measures angular position north or south of the equator on the reference ellipsoid. Their usual unit is degrees.

On an ordinary north-up map, longitude behaves like the horizontal direction and latitude like the vertical direction. That creates a natural analogy:

x-like direction -> longitude
y-like direction -> latitude

This is why so much GIS and programming software uses longitude as x and latitude as y.

The analogy is especially visible in GeoJSON. RFC 7946 defines a position with the first two elements in longitude-latitude order, following the x-y convention. A point at longitude 12 and latitude 4 is written:

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

But that does not mean every representation of WGS 84 coordinates is required to use longitude first.

CRS axis order can differ from software convention

The formal axis order of EPSG:4326 is latitude, then longitude. PROJ's documentation highlights the same distinction: authority-defined geographic CRSs often follow their formal latitude-longitude axis order, while software-oriented conventions and PROJ strings commonly use longitude-latitude.

This is one reason statements such as "x is always longitude" become dangerous when they are turned into universal rules.

Three layers of convention can be involved at once:

The CRS defines the coordinate system, axes, units and reference frame.
The data format defines how coordinates are serialised.
The software interface defines the order and labels in which it accepts or returns values.

The same geographic location can therefore appear as latitude-longitude in one standards-aware context and longitude-latitude in another without either system being internally inconsistent.

The live guide Latitude vs Longitude: Which Comes First? treats that ordering problem directly. The narrower point here is that x/y terminology is not enough to resolve it.

Projected x and y are not longitude and latitude

Projected coordinate systems convert positions on the curved Earth into a planar coordinate space. The resulting coordinates are commonly described as eastings and northings, often measured in metres or feet.

In that context:

x often corresponds to easting
y often corresponds to northing

Those numbers are not longitude and latitude written differently; converting between projected and geographic coordinates requires a coordinate transformation using the correct source and destination CRSs.

Renaming x to longitude and y to latitude does not transform anything. If 500000 metres is interpreted as 500000 degrees, the problem is not formatting; the coordinate has been given the wrong meaning.

That distinction is useful when diagnosing files that plot far from their expected location. Before swapping axes, ask whether the values are even geographic degrees.

Column names are evidence, not proof

Real datasets often contain ambiguous field names:

x, y;
coord1, coord2;
lat, lon;
easting, northing;
longitude, latitude.

Specific names are better than generic ones, but they can still be wrong because columns are renamed, copied between systems and inherited from templates. A field called longitude can therefore contain an easting if an earlier import was misunderstood.

The values themselves provide additional clues. Geographic latitude is constrained to -90 to 90 degrees, while longitude normally falls between -180 and 180 degrees. Projected values often have much larger magnitudes, although local grids can be small enough to remain ambiguous.

Units, metadata, file format and expected extent should therefore be read together.

A reliable way to interpret x-y fields

When you encounter an unfamiliar coordinate pair, use a sequence that reduces ambiguity rather than relying on one convention.

1. Identify the CRS if it is declared. The CRS establishes the coordinate space, units and formal axes. If it is missing, do not guess from the field names alone.

2. Inspect the units and magnitudes. Values such as 9.7, 4.1 are plausible geographic degrees. Values such as 620000, 5150000 are more likely projected coordinates, though the CRS is still needed to interpret them.

3. Check the format or API contract. GeoJSON explicitly uses longitude-latitude. Another API may expose named {lat, lng} fields. Follow the representation actually being used.

4. Test a known position. Plot or transform one location whose approximate position is known. A correct interpretation should agree with the expected geography without requiring ad hoc fixes.

5. Preserve explicit names once the meaning is known. longitude_deg, latitude_deg, easting_m and northing_m are harder to confuse than x1 and x2.

Use the most specific terminology available

The words you choose can make errors easier or harder to detect.

Use longitude and latitude when you mean geographic angular coordinates. Use easting and northing when that is what a projected CRS defines. Use x and y when the discussion is genuinely about generic coordinate axes or a software interface that exposes those labels.

This is more than stylistic neatness. Calling every horizontal value "longitude" can hide the fact that a projected dataset has been mistaken for geographic data. Calling every first coordinate "x" can hide a latitude-first CRS axis definition.

The most useful rule is therefore not "x equals longitude and y equals latitude". It is:

Interpret x and y in the coordinate system that defines them.

When that system is geographic and the representation follows the familiar x-y convention, x will usually correspond to longitude and y to latitude. When it is not, the labels can mean something entirely different.

References

IETF RFC 7946 - The GeoJSON Format. Defines GeoJSON positions with longitude followed by latitude for geographic coordinates.
PROJ FAQ - Why is the axis ordering in PROJ not consistent?. Explains the difference between authority-defined CRS axes and common GIS/software coordinate ordering.