Turning Coordinates into Grid Squares: The Maidenhead Locator Explained — Annotated Notes & Key Takeaways

If you have ever operated in a VHF contest, chased a satellite, or logged a contact for an award, you have probably been asked for your Grid Square. The Maidenhead Locator System is the standard way hams describe their position without reciting a string of latitude and longitude numbers. It is compact, easy to say over the air, and precise enough for most operating. But how do you actually convert a pair of coordinates into a grid square? The material here explains the algorithm, provides implementations in multiple programming languages, and highlights some of the subtleties that trip people up. What follows is a reader's guide to the main points, the code examples, and the parts that remain unclear.
 

The Basic Algorithm: Longitude First, Then Latitude

The core of the conversion is a simple pair of calculations, one for longitude and one for latitude. The material lays this out clearly. The first pair of characters in a grid square represents a large field. The second pair represents a smaller square within that field. The third pair, usually written in lowercase, represents an even smaller subsquare. If you want more precision, you can add a fourth and fifth pair, which encode even finer divisions.
 

For longitude, the algorithm starts by adding 180 to the coordinate. That shifts the range from -180 to 180 into the range 0 to 360. Then you divide by 20 and take the integer part. That gives you a number from 0 to 17. Add one, and you get a number from 1 to 18. That number corresponds to a letter of the alphabet, usually written in uppercase. The first field is 20 degrees of longitude wide, which is why the division is by 20.
 

For latitude, the process is similar but the numbers are different. You add 90 to shift the range from -90 to 90 into 0 to 180. Then you divide by 10 and take the integer part. That gives you a number from 0 to 17. Add one, and you get a letter from A to R. The first field is 10 degrees of latitude tall, which is why the division is by 10.
 

Once you have the first letter for longitude and the first letter for latitude, you move on to the numbers. For longitude, you take the remainder from the first division, divide by 2, and round down. That gives you a digit from 0 to 9. For latitude, you take the remainder, round down, and that gives you another digit from 0 to 9. These two digits form the second pair of the grid square.
 

The third pair is the subsquare. For longitude, you take the remainder from the second step, multiply by 12, and round down. That gives you a number from 0 to 11, which maps to a lowercase letter. For latitude, you take the remainder, multiply by 24, and round down. That gives you a number from 0 to 23, which maps to another lowercase letter.
 

The material walks through an example: 32.123 W, 14.321 N. The longitude calculation gives H, then 3, then w. The latitude calculation gives K, then 4, then h. Put them together in the right order — longitude letter, latitude letter, longitude digit, latitude digit, longitude subsquare, latitude subsquare — and you get HK34wh. That is the grid square for that location.
 

One point I found a bit confusing at first is the order of the pairs. Longitude always comes first, followed by latitude, for each pair. So the grid square is not simply the longitude string followed by the latitude string. It is interleaved. That is easy to miss if you are skimming, and it is a common source of errors in hand calculations.
 

Code Implementations Across Languages

The material includes implementations in Python, C, Java, C#, JavaScript, Clojure, and Swift. That is a lot of code, and it reflects the fact that this conversion is a common need in logging software, contest tools, and satellite trackers. The Python version is the most fully documented, with a self-test that checks the function against known coordinates. The test cases come from a 1989 QST article by Edmund Tyson, N5JTY, and include locations like Munich, Montevideo, Washington DC, and Wellington. That is a useful set of reference points for anyone implementing their own version.
 

The C version is designed for an Arduino project, which suggests that the conversion is simple enough to run on a microcontroller. That is not surprising — the arithmetic is basic, and the memory footprint is tiny. The Java version includes a JUnit test case, which makes it easy to verify correctness. The C# version follows the same structure. The JavaScript version is written to be compatible with the LatLon library by Chris Veness, which means it can accept coordinates as numbers, strings, or getter functions.
 

The Clojure version is notable because it supports extended precision. The standard Maidenhead system uses three pairs, but you can add a fourth and fifth pair for even finer resolution. The Clojure code encodes those extra pairs, which makes it useful for applications that need more than the standard six-character locator. The Swift version also supports extended precision and is written in a functional style that avoids some of the repetitive code in the other implementations.
 

One thing that stands out across all these implementations is that they follow the same basic algorithm. There is no controversy about how the conversion works. The differences are mostly in style, language features, and how the code handles input validation. The Python version, for example, checks that the latitude and longitude are within valid ranges and raises an error if they are not. The Java version does the same. That is good practice, because a grid square is undefined at the poles and outside the normal coordinate ranges.
 

The material also mentions PyHamTools, a Python library that includes locator calculations. If you are writing Python and do not want to implement the algorithm yourself, that is a good option. It also includes distance and heading calculations, which are useful for contesting and award tracking. The library is open source and well documented.

Extended Precision and the Limits of the System

The standard Maidenhead locator has six characters: two uppercase letters, two digits, and two lowercase letters. That gives a resolution of about 5 minutes of longitude by 2.5 minutes of latitude, which is roughly 7 by 4 kilometers at mid-latitudes. For most VHF and UHF work, that is plenty. But some applications need more precision, and the material describes how to extend the system.
 

The fourth pair adds another digit for longitude and another digit for latitude. The longitude digit is calculated by taking the remainder from the third step, multiplying by 10, and rounding down. The latitude digit is calculated similarly, multiplying by 10. The fifth pair adds another lowercase letter, using the same multipliers as the third pair: 24 for longitude and 24 for latitude. The exact details are in the code examples, and the Clojure and Swift implementations both show how to do it.
 

One limitation that the material does not fully address is how the extended precision interacts with GPS accuracy. If your GPS is only accurate to a few meters, adding more digits to the locator does not make your position more accurate. It just gives you a false sense of precision. The material does not discuss this, but it is a practical consideration. For most amateur radio purposes, the standard six-character locator is more than enough.
 

Another limitation is that the Maidenhead system is based on a simple rectangular grid. It does not account for the curvature of the Earth or for the fact that lines of longitude converge at the poles. That is why the system is invalid at the poles. The material mentions this in passing, but it does not explore the consequences. For most operators, this is not an issue, because there are very few hams operating at the poles. But it is a reminder that the grid is a convenience, not a precise geodetic system.
 

The material also does not discuss how to convert from a grid square back to latitude and longitude. That is a related problem, and it is mentioned in a linked question. But it is not covered here. If you need to go in both directions, you will need to look elsewhere.
 

Where the Material Leaves Gaps

The biggest gap in the material is the lack of a clear explanation of why the algorithm works. It gives the steps, and the code is correct, but it does not explain the reasoning behind the numbers. Why divide longitude by 20 and latitude by 10? Why multiply by 12 and 24 for the subsquares? The answers are in the geometry of the grid, but the material does not spell them out. A reader who wants to understand the system, not just implement it, would need to look at the Wikipedia article or the original QST paper.
 

The material also does not discuss the history of the Maidenhead Locator System. It was developed in the 1980s for VHF contests in the United Kingdom, and it was named after the town of Maidenhead where the first meeting took place. That is interesting context, and it helps explain why the system uses the specific divisions it does. But the material does not include it. A reader who is curious about the origins of the system would need to look elsewhere.
 

Another gap is the lack of a simple online calculator that readers can use without writing code. The material mentions a few links, including a grid square map and a QRZ calculator, but it does not provide a direct link to a simple converter. That would be useful for someone who just wants to find their own grid square without implementing the algorithm.
 

There is also a minor disagreement about the order of operations in the longitude calculation. The accepted answer says to take the integer value of the division by 20 and then add one. The Python code does the same thing, but it uses a different method to compute the remainder. The results are the same, but the presentation is different. That is not a problem, but it can be confusing for someone who is trying to follow along.
 

The material also does not address what happens when the coordinate is exactly on a boundary. For example, if your longitude is exactly 180 degrees, the calculation gives a specific result, but the material does not discuss whether that is the intended behavior. It is an edge case, but it is the kind of thing that can cause bugs in logging software.
 

What I take away from all this is that the Grid Square conversion is a solved problem. The algorithm is simple, the code is available in many languages, and there are libraries that do the work for you. The material is a useful reference for anyone who needs to implement the conversion or understand how it works. It is not a complete tutorial, and it leaves some questions unanswered, but it gives you the tools to get started. The Maidenhead Locator System is one of those small pieces of infrastructure that makes amateur radio work, and it is worth understanding, even if you never have to write the code yourself. The Grid Square is a compact way to say where you are, and the material shows you how to find it.