Lat lon to MGRS
Enter 38.8895, -77.0353 and get the MGRS reference 18SUJ2347806483, ready for a topographic map, a land-navigation drill or a radio brief. The digits are truncated, so the point always stays inside the named square. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Latitude
- 38.8895
- Longitude
- -77.0353
- Precision
- 5
- Mgrs
- 18SUJ2347806483
- Gzd
- 18S
- Square id
- UJ
- Easting digits
- 23478
The Military Grid Reference System turns a WGS84 latitude and longitude into a compact alphanumeric grid string used on topographic maps, land navigation courses, and many defense and emergency workflows. This capability projects your coordinates with standard UTM between eighty degrees south and eighty-four degrees north, or UPS in the polar caps, then attaches the grid-zone designator, the two-letter one-hundred-kilometer square, and a truncated numerical easting and northing at the precision you choose from zero through five digits. Precision above five digits or coordinates outside the valid latitude and longitude ranges fail with a clear invalid input error.
What MGRS encodes and which lat, lon, and precision to send
An MGRS coordinate is a single string that packs three layers of location. First comes the grid-zone designator: for most of the world that is a one- or two-digit UTM zone number followed by a latitude band letter from C through X, skipping I and O. Second is a two-letter one-hundred-kilometer square identifier whose column and row letters follow the NGA lettering tables that cycle with zone number.
Third is the numerical location: equal-length easting and northing digit groups that refine the position inside that square. Precision zero returns only the designator and square letters; precision one is about ten kilometers; two is one kilometer; three is one hundred meters; four is ten meters; five is one meter. Optional precision, also accepted as digits or accuracy, defaults to five when omitted.
Latitude must lie between minus ninety and ninety inclusive; longitude between minus one hundred eighty and one hundred eighty.
Reading the MGRS response, UTM fields, and truncation rules
The system field is UTM or UPS depending on whether the point falls inside the standard UTM latitude band or the polar caps. Zone, band, and hemisphere describe the intermediate projected frame; the utm object exposes easting and northing in meters for debugging against other projection libraries. Numerical digits are truncated, not rounded, toward the southwest corner of the finest square—the same rule field manuals and NGA software use so a reported point always lies inside the named grid square.
Prefer the structured fields when building tables; keep the single mgrs string when you must print a radio brief or fill a map annotation.
Where the grid reference helps, and its limits
Call the free in-browser lat lon to MGRS tool for land-navigation drills, lecture demos, and quick mental checks without installing GeoTrans, PROJ, or a desktop GIS. Norway and Svalbard use the standard UTM zone exceptions so Scandinavian points match published charts. Polar UPS encoding covers latitudes above eighty-four north and below eighty south with zone letters A, B, Y, and Z.
Authors shipping SDKs can map the mgrs field directly into message templates and form defaults that operators already recognize from paper maps.
What you can do with it
Land navigation and map annotation
Instructors and field teams convert GPS lat/lon readouts into MGRS strings that match topographic map grids and radio reporting formats at 10 m or 1 m precision.
GIS and emergency planning pipelines
Backends normalize incident coordinates to MGRS for shared operational pictures, after-action reports, and interoperability with systems that store grid references.
Training simulators and CI oracles
Simulators and automated tests pin known lat/lon pairs to expected MGRS strings so projection refactors cannot silently drift from NGA-style lettering.
FAQ
How do I convert latitude and longitude to MGRS?
Optional precision (0–5, default 5) sets how many easting and northing digits appear after the 100 km square letters.
Are polar coordinates supported?
Yes. Points north of 84°N or south of 80°S use UPS polar stereographic encoding with MGRS zone letters A, B, Y, or Z instead of a numeric UTM zone.
Is the lat lon to MGRS converter free?
The browser tool runs free on your device.
Does MGRS round or truncate the numerical digits?
Digits are truncated toward the southwest of the grid square, matching common field and NGA practice so the reported point always lies inside the named square.
Which MGRS precision should I pick?
Choose by how exact the spot must be: one digit per axis is about 10 km, two is 1 km, three is 100 m, four is 10 m and five, the default, is 1 m. Zero gives only the zone and square letters.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/geo/mgrs-from-latlon \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"lat":38.8895,"lon":-77.0353}'const res = await fetch("https://api.kit.forhosting.com/geo/mgrs-from-latlon", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"lat": 38.8895,
"lon": -77.0353
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/geo/mgrs-from-latlon",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"lat": 38.8895,
"lon": -77.0353
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/geo/mgrs-from-latlon", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"lat":38.8895,"lon":-77.0353}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"lat":38.8895,"lon":-77.0353}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/geo/mgrs-from-latlon", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"lat": 38.8895,
"lon": -77.0353
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "geo.mgrs_from_latlon",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Students, GIS engineers, and backend services get deterministic JSON they can pin in tests without embedding a full GeoTrans stack.
What MGRS encodes and which lat, lon, and precision to send
Send required fields lat and lon as decimal degrees on the WGS84 ellipsoid, with aliases latitude or y for lat and lng, longitude, or x for lon when your client already uses those names. Values above five for precision, non-finite numbers, or coordinates outside those ranges fail with invalid_input so pipelines never accept a silently clipped grid. Identical inputs always produce identical JSON because the path is pure projection arithmetic with no network, no random seed, and no wall clock.
Reading the MGRS response, UTM fields, and truncation rules
On success the response echoes lat, lon, and precision, returns the full mgrs string, and splits it into gzd, square_id, easting_digits, and northing_digits so clients can display or validate parts without re-parsing the string by hand. The method label is always mgrs_from_wgs84 so downstream code can branch without sniffing shapes when you mix this encoder with geohash or quadkey tools.
API usage, pricing, navigation workflows, and practical limits
Send a JSON body with required numbers lat and lon and optional integer precision between zero and five. Use the prepaid API when a mapping backend, search-and-rescue planner, military training simulator, outdoor app, or educational platform needs a stable contract under KIT balance at $0.002 per successful item; validation failures never consume balance after the engine rejects the request. Pair this endpoint with your own reverse MGRS decoder or distance tools when the next step is a route or a bounding box around a reported grid.
Technical questions
What happens if precision is greater than five?
The request fails with invalid_input. This capability supports at most five digits per axis (about one meter); finer precision is out of scope and is not charged.