Why are my coordinates in the wrong place?

A coordinate is only meaningful when you know the context it was created in. That context includes the format the coordinate is written in, the coordinate system it belongs to, and the datum it is tied to. If any one of those is wrong or assumed incorrectly, the point will plot in the wrong place, even if every digit is technically correct.

The difficulty is that many of these problems are invisible. The coordinate does not look broken. It does not throw an error. It simply lands somewhere it should not. That is what makes "wrong place" problems harder to debug than obviously malformed input.

In practice, almost every "wrong place" problem falls into one of five categories: reversed coordinate order, wrong format assumption, wrong coordinate system, wrong datum, or a combination of more than one.

This is the single most common reason coordinates plot in the wrong place, especially for users who are not working with coordinates every day. Latitude measures north/south position and should come first. Longitude measures east/west position and should come second. Swapping them produces a coordinate that still looks valid but points to a completely different location.

For example, the coordinate 51.5074, -0.1278 points to central London. If those values are accidentally reversed to -0.1278, 51.5074, the result is a point in the Atlantic Ocean, west of Africa. Both pairs are numerically valid. Only the order is wrong.

This mistake is especially easy to make when coordinates are copied from spreadsheets, databases, or APIs where column headers may be ambiguous or absent. Some systems store longitude first (GeoJSON, for instance), which further adds to the confusion.

Coordinates come in many different formats. A value in DMS (Degrees Minutes Seconds) looks very different from one in Decimal Degrees, even though both describe latitude and longitude. If a DMS value is pasted into a tool that expects Decimal Degrees, or vice versa, the plotted point will be wrong.

For example, the DMS coordinate 51°29'19.9"N is equivalent to 51.4889 in Decimal Degrees. If someone enters "512919.9" as a decimal number instead of parsing the degrees, minutes, and seconds properly, the result is meaningless. The same goes for DDM (Degrees Decimal Minutes), which looks similar to DMS but handles the fractional part differently.

This problem is most common when coordinates are copied from older documents, PDFs, printed maps, or handwritten field notes where the formatting does not survive the copy process cleanly.

A coordinate system defines the rules behind the numbers. Latitude and longitude are measured in degrees on a globe. UTM is measured in metres within a numbered zone. British National Grid is measured in metres within a UK-specific flat grid. These systems produce completely different-looking numbers for the same place.

If a UTM value is treated as though it were Easting/Northing without considering the zone, or if a British National Grid coordinate is treated as generic latitude and longitude, the result will be wrong by a very large margin. This is not a subtle offset. It is usually hundreds or thousands of kilometres out.

The key insight is that the numbers alone do not tell you the system. You need to know what system the source was using before you can interpret or convert the values correctly. If the system is unknown, the safest approach is to compare the values against the format patterns shown in the table above and rule out options one by one.

If you have a bare pair of numbers and no idea which system they belong to, the Coordinate Format Identifier does that elimination for you. It converts the pair through each system it could plausibly be and ranks the interpretations by how well the resulting location holds up.

A datum is the mathematical model of the Earth that a coordinate is tied to. Two coordinates can use the same format and the same coordinate system but still point to different places if they are based on different datums. This is the most deceptive category of "wrong place" problems because the coordinate looks entirely correct.

The most common real-world example is the difference between WGS84 and OSGB36 in the UK. WGS84 is the datum used by GPS devices, smartphones, and Google Maps. OSGB36 is the datum used by Ordnance Survey and British National Grid. The same physical location has slightly different latitude and longitude values in each datum. The offset between WGS84 and OSGB36 can be up to about 120 metres in Great Britain.

That means a latitude/longitude pair copied from an Ordnance Survey source will plot approximately 100 metres away from the true location if pasted into Google Maps without a datum transformation. The numbers look perfectly clean. The point just lands in the wrong place.

In practice, coordinates often arrive with more than one problem. A value might be in the wrong format and the wrong order. Or it might be in the right format but the wrong datum, and also missing the UTM zone. When two or more issues overlap, the resulting plotted point can be so far off that it is hard to even begin diagnosing which part went wrong.

The most reliable approach in this situation is to work through the diagnostic checklist methodically rather than trying to fix everything at once. Identify the format first, then confirm the coordinate system, then check the datum. Solving problems in that order prevents one fix from masking another problem underneath.

When a coordinate plots in the wrong place, work through these questions in order. Each one eliminates a category of problem and narrows the search:

The distance between the plotted point and the expected location is itself a useful diagnostic clue. Different types of errors produce different scales of displacement:

Example 1: A project manager receives a coordinate from a survey report: 530034, 179382. She pastes it into Google Maps, which expects latitude and longitude. Google Maps tries to interpret 530034 as a latitude, which is far beyond the valid range of -90 to 90. The point does not appear, or appears in a nonsensical location. The fix: recognise that 530034, 179382 is a British National Grid Easting/Northing pair, not a latitude/longitude pair, and convert it properly.

Example 2: An ecologist copies 51.5074, -0.1278 from a GPS reading and pastes it into a GIS project that expects OSGB36. The point plots about 100 metres from the actual field location. The numbers look correct and the point is close, but the datum is wrong. The fix: either convert the GPS coordinate from WGS84 to OSGB36 before importing, or set the GIS project to WGS84.

Example 3: A hiker copies "TQ 301 800" from an Ordnance Survey map and types it into a mapping app as "301, 800". The app interprets these as latitude and longitude, which are invalid values. The fix: keep the grid square letters (TQ) and enter the full UK Grid reference.

CoordinateMapper is designed to handle exactly these kinds of problems. It auto-detects the input format, so you do not need to know in advance whether the coordinate is DD, DMS, UTM, UK Grid, or Easting/Northing. Once the format is recognised, the tool converts the coordinate into every supported output format and plots it on the map immediately.

That instant visual check is the fastest way to confirm whether the coordinate is landing where you expect. If it is not, you can adjust the format assumption, try swapping the order, or test a different interpretation without needing to switch between tools.

For bulk data, CoordinateMapper processes one coordinate per line and flags any entries it cannot parse, which makes it easy to isolate the problem coordinates and fix them individually.

Most "wrong place" problems are preventable with a small amount of discipline at the point where coordinates are created, shared, or stored:

Coordinates that plot in the wrong place are almost always a context problem, not a typing problem. The five most common causes are reversed order, wrong format, wrong coordinate system, wrong datum, and overlapping combinations of these. Working through the diagnostic checklist in order, from format to datum, is the fastest way to isolate and fix the issue. And plotting the result on a map before using it elsewhere is the single most effective prevention step you can take.