Why Is My Map Marker in the Wrong Place? 5 Coordinate Mistakes Developers Make

You have a latitude and longitude. You pass them to a map, add a marker, and zoom in. The marker appears on another continent, in the ocean, or a few streets away from where you expected.

The map may be rendering correctly. The problem is often in the coordinates you gave it—or in what you assumed those coordinates meant. Here are five checks I use when debugging a misplaced marker.

1. Latitude and longitude are in the wrong order

A browser's Geolocation API gives you named properties: latitude and longitude. MapLibre GL JS expects an array in longitude, latitude order. GeoJSON uses the same order.

navigator.geolocation.getCurrentPosition(({ coords }) => {
  const { latitude, longitude } = coords;

  // Wrong: [latitude, longitude]
  // marker.setLngLat([latitude, longitude]);

  // Correct: [longitude, latitude]
  marker.setLngLat([longitude, latitude]);
});

For New York, 40.7128, -74.0060 is a familiar latitude, longitude pair. A MapLibre array for that location is [-74.0060, 40.7128].

This bug can be hard to spot when both numbers fall within valid latitude and longitude ranges. The map may show a real location, just the wrong one.

Check: Find the coordinate order in the documentation for every API boundary. Don't infer it from the phrase “lat/lon” in a UI label.

2. The numbers belong to a different coordinate reference system

A pair of numbers is incomplete without its coordinate reference system (CRS). WGS84 longitude and latitude are expressed in degrees. Web Mercator coordinates, commonly associated with EPSG:3857, are expressed in projected units such as metres.

If a data source gives you Web Mercator x and y, you cannot pass them to a function that expects [longitude, latitude] in degrees and hope the map will work it out.

// Conceptual example: these are projected x/y values,
// not longitude and latitude in degrees.
const point = { x: -8238310, y: 4970072, crs: "EPSG:3857" };

// Wrong: marker.setLngLat([point.x, point.y]);
// First transform the point to geographic longitude/latitude
// using an appropriate CRS transformation library or service.

The same warning applies when combining GPS data with coordinates from a local or regional map system. Label the source CRS, transform where necessary, and only then display the result.

Check: Do you know the CRS and units of the input? Values in the millions are a strong clue that they are not ordinary longitude and latitude in degrees.

3. You treated a formatted coordinate as a decimal number

A coordinate such as 40°42'46.08"N is in degrees, minutes, and seconds (DMS). It represents about 40.7128°, not 40.424608° and not the JavaScript number 40.

For one component, the conversion is:

function dmsToDecimal(degrees, minutes, seconds, hemisphere) {
  const value = degrees + minutes / 60 + seconds / 3600;
  return hemisphere === "S" || hemisphere === "W" ? -value : value;
}

const latitude = dmsToDecimal(40, 42, 46.08, "N");
const longitude = dmsToDecimal(74, 0, 21.6, "W");

console.log([longitude, latitude]); // [-74.006, 40.7128]

The function above converts already parsed DMS parts; it is not a parser for arbitrary text. If users paste coordinates, parse the separators and hemisphere letters explicitly, then validate the result. parseFloat("40°42'46.08\"N") will silently return 40, which can be especially misleading.

DMS to decimal degrees is a format conversion. It does not transform coordinates between WGS84 and another CRS.

Check: Inspect the raw input string and the numeric value immediately before adding the marker.

4. A hemisphere or minus sign was lost

Latitude is positive north of the equator and negative south. Longitude is positive east of the prime meridian and negative west. If you drop the W from 74°W, your marker moves from the western hemisphere to the eastern one.

This often happens while cleaning form input or exporting CSV data:

const input = "74.0060 W";
const longitude = parseFloat(input); // 74.006: the W is ignored

A safe parser needs to apply the hemisphere sign deliberately. It should also reject contradictory inputs such as -74 W unless you define exactly how your app handles them.

Before rendering, validate the basic ranges:

function isValidLngLat(longitude, latitude) {
  return Number.isFinite(longitude) &&
    Number.isFinite(latitude) &&
    longitude >= -180 && longitude <= 180 &&
    latitude >= -90 && latitude <= 90;
}

Range checks catch impossible numbers. They cannot reliably detect reversed coordinates when both values are plausible.

Check: Preserve N/S/E/W or signed values throughout parsing, storage, and export. Test at least one western and one southern hemisphere location.

5. You expected an approximate location to be exact

Sometimes the marker is in the right general area but not at the user's actual position. That may be a data quality issue rather than a mapping bug.

Browser geolocation can use different sources, including GPS, Wi-Fi, and network information. Its result includes an accuracy value in metres. An IP-based location is typically an approximate area and should not be presented as an exact device position.

navigator.geolocation.getCurrentPosition(({ coords }) => {
  marker.setLngLat([coords.longitude, coords.latitude]);
  console.log(`Reported accuracy: ${coords.accuracy} metres`);
});

If your app falls back to IP location after permission is denied, label that fallback clearly. Zooming to street level does not make an approximate coordinate more accurate.

Check: Show the location source and reported accuracy when available. Debug the input's precision before adjusting marker code.

A quick debugging checklist

When a marker appears in the wrong place, log the coordinate at the point where it enters the app and again just before it reaches the map:

console.table({
  source: "browser geolocation", // or your actual data source
  crs: "WGS84",
  longitude,
  latitude,
  valid: isValidLngLat(longitude, latitude)
});

marker.setLngLat([longitude, latitude]);

Then ask:

1. Does this API want [longitude, latitude] or [latitude, longitude]?
2. What CRS and units did the source use?
3. Was a DMS string parsed into decimal degrees correctly?
4. Did any minus sign or hemisphere letter disappear?
5. Is the source location approximate?

If you are unsure which coordinate system your data uses, inspect a sample point before processing the full dataset. You can use CoordMap's coordinate converter to compare supported systems and check the result on a map.

The most useful habit is simple: carry order, format, CRS, and accuracy alongside the numbers. Two coordinates alone rarely tell the whole story.