The geo: URI encoder turns latitude, longitude and an optional altitude into a valid RFC 5870 geo: URI — the standard, app-neutral way to point at a physical location. Many mobile platforms open a map when a geo: link is tapped, so it doubles as a share link or QR-code map pin.
How it works
RFC 5870 defines the syntax geo:lat,lon[,alt][;crs=...][;u=...]. Latitude (-90 to 90) comes first, then longitude (-180 to 180), both in decimal degrees on the WGS-84 coordinate reference system that is the default. An optional third comma-separated value is the altitude in metres. The u parameter records positional uncertainty as a radius in metres.
The encoder validates that the two angles are real numbers in range, then assembles the components. Because numeric coordinates and standard parameters need no escaping, the output is the plain geo: string. Altitude and u are appended only when supplied.
Example
Lat 48.2010, Lon 16.3695, alt 183, u 25
-> geo:48.201,16.3695,183;u=25
A coordinate at the equator and prime meridian is simply geo:0,0.
Where geo: URIs are used
HTML links and email. An <a href="geo:51.5074,-0.1278">London</a> link opens the user’s default map application on Android and many desktop platforms. It is more portable than a Google Maps or Apple Maps URL because it is not tied to a specific mapping service.
QR codes. Encode the geo: string as a QR code and scanning it with a phone camera will prompt the device to open the location in its map app. This is commonly used on printed signs, information boards, and event materials.
NFC tags and deep links. The geo: scheme works in NFC NDEF records and is recognized by Android’s NFC reader as a map-open intent. It is smaller than a full URL and avoids any dependency on a third-party mapping service.
APIs and data exchange. When your application stores or transmits location data as a URI, geo: is the standard choice. It avoids encoding ambiguity because decimal-degree coordinates and the standard parameters never require percent-encoding.
Common mistakes to avoid
Longitude before latitude. The geo: spec is latitude first, then longitude. Many web map APIs (Google Maps JavaScript API, Leaflet) accept longitude-first arrays internally, which leads developers to accidentally swap the order in a geo: URI. The pin lands in the ocean or the wrong hemisphere.
Excessive precision. Storing 15 decimal places in a URI makes it long without adding any practical accuracy. Six decimal places (about 0.11 m precision) is more than enough for any location-sharing use. The encoder keeps whatever digits you enter, so round your inputs sensibly.
Including the crs parameter unnecessarily. WGS-84 is the default and implied. Only add crs=wgs84 if you have a specific reason; most parsers treat it as redundant and some older parsers reject unknown parameters.
Platform support for geo: links
Android handles geo: URIs natively — tapping a geo: link opens the default maps application. iOS support is more fragmented: Safari on iOS may not open a map from a geo: link without a fallback, since Apple Maps prefers its own URL scheme. A common pattern for web pages targeting both platforms is to detect the user agent and serve an <a href="geo:..."> for Android and an Apple Maps URL for iOS, or to use the geo: URI in contexts (email, NFC, QR) rather than web links where iOS behavior is less predictable.
Desktop browsers generally do not handle geo: URIs unless the user has configured a handler. In a web page, geo: links are most reliable on mobile where a maps app is the expected destination.
Notes
The output fits directly in an <a href="geo:..."> link. Everything runs locally; your coordinates are never uploaded.