Why are my coordinates not showing on the map?

When a coordinate does not show on the map, most people assume the map is broken or the tool has a bug. In reality, the problem is almost always in the input. The coordinate string is either malformed, incomplete, out of range, in an unrecognised format, or mixed with extra text that prevents the parser from extracting the location cleanly.

Map tools need to convert your text input into a pair of numbers (latitude and longitude, or easting and northing) before they can place a point. If that conversion fails at any step, nothing gets plotted. The frustrating part is that many tools fail silently. They do not show an error. The point simply does not appear.

Understanding the common failure points makes it much easier to diagnose the problem and fix it in seconds rather than minutes.

Every coordinate format has a valid range. If a value falls outside that range, the tool cannot plot it because the location does not exist on Earth. Latitude must be between -90 and +90. Longitude must be between -180 and +180. If either value exceeds these limits, the coordinate is invalid.

This often happens when latitude and longitude are accidentally swapped. A longitude value like -122.4194 (San Francisco) is valid as a longitude but invalid as a latitude because it exceeds 90. If the tool tries to interpret it as latitude, the coordinate fails.

For projected coordinates like UTM or British National Grid, the valid ranges are different but equally strict. A UTM easting is typically between 100,000 and 900,000 metres. A British National Grid easting ranges from 0 to about 700,000. Values outside these ranges will not parse correctly.

This is extremely common when coordinates are copied from emails, PDFs, reports, or spreadsheets. The coordinate itself may be valid, but it arrives wrapped in labels, descriptions, units, or surrounding text that prevents the parser from isolating the numbers.

For example, "Latitude: 51.5074 N, Longitude: 0.1278 W (approximate)" contains a valid coordinate, but the words "Latitude:", "Longitude:", and "(approximate)" are all extra content that many parsers cannot handle. The fix is to strip the input down to just the coordinate values.

If a tool is set to expect Decimal Degrees but you paste a DMS value, or if it expects UTM but you paste a UK Grid reference, the input will fail to parse. The numbers might be perfectly valid in their original format but completely meaningless in the format the tool is trying to apply.

CoordinateMapper uses auto-detection by default, which avoids most of these issues. But even with auto-detection, ambiguous inputs can occasionally be misinterpreted. If you are not sure what format you are holding, the Coordinate Format Identifier will name it before you try to convert it.

A coordinate needs all of its parts to work. For latitude/longitude, that means two values. For UTM, that means a zone, an easting, and a northing. For UK Grid, that means two letters and an even number of digits. If any part is missing, the coordinate cannot be plotted.

Incomplete coordinates are especially common when data is copied from narrow spreadsheet columns that cut off the content, or when coordinates are extracted from PDFs where the text reflow breaks the value across lines.

Coordinates use specific punctuation: degree symbols (°), single quotes ('), double quotes ("), commas, spaces, and sometimes hemisphere letters (N, S, E, W). If any of these are wrong, duplicated, missing, or replaced with look-alike characters, the parser may fail.

A common culprit is the degree symbol. There are several characters that look like a degree symbol but are not: the masculine ordinal indicator (º), the ring above (˚), and various Unicode alternatives.

Another common issue is comma vs period for decimal separators. In many European countries, a comma is used as the decimal separator (51,5074 instead of 51.5074).

When pasting multiple coordinates at once, the tool typically expects one coordinate per line. If coordinates are separated by something other than line breaks, the parser cannot distinguish where one coordinate ends and the next begins.

Another common issue with bulk data is inconsistent formatting across lines. If some lines are in DD, others in DMS, and others in UTM, a tool that processes all lines with the same format assumption will fail on the lines that do not match.

When a coordinate does not show on the map, work through these steps in order:

Scenario 1: You copy "E 530034 N 179382" from a planning document. The tool does not recognise it because the "E" and "N" labels are not standard coordinate formatting. Fix: remove the letters and enter "530034, 179382" as Easting/Northing.

Scenario 2: You paste "51° 29’ 19.9” N, 0° 0’ 52.5” W" from a Word document. The smart quotes are not standard ASCII quote marks. Fix: replace the curly quotes with straight quotes.

Scenario 3: You paste a column of 50 coordinates from Excel. 48 plot correctly, but 2 do not appear. The missing rows have a trailing space or a hidden newline character. Fix: trim whitespace from the failing lines.

Scenario 4: You enter "TQ379785" without a space between easting and northing digits. Fix: add a space: "TQ 379 785".

CoordinateMapper is built to be forgiving with input formatting. It auto-detects the coordinate format, handles flexible spacing and punctuation, accepts both standard and common non-standard degree symbols, and processes bulk input one line at a time so that a single bad line does not block the rest of your data.

When a coordinate cannot be parsed, it appears in the error list rather than disappearing silently. That makes it easy to identify which specific inputs need cleaning and what might be wrong with them.

When coordinates do not show on the map, the problem is almost always in the input, not the map. The most common causes are out-of-range values, extra text mixed in with the coordinate, a format mismatch between the input and what the tool expects, incomplete coordinates, and separator or encoding issues. Working through the diagnostic steps in order resolves most problems quickly.