Drop a Pin — Map Deep Links

Why so many URL schemes?

There's no single "open this point in a map" URL the way there's a single mailto: for email or tel:for phone. Each mapping platform controls its own URL grammar; a Google Maps link won't open Apple Maps and vice-versa. The universal geo: URI, defined in IETF RFC 5870 (2011), is the closest thing to a cross-platform standard — tapping a geo:link on a mobile device opens whichever map app the OS defaults to. But desktop browsers don't handle geo: by default, so for the web you still need a platform-specific HTTP(S) link.

This tool generates the full set so you can pick the right one. As a rule of thumb:

• Talking to one person, know their phone? Send the platform-specific link (Google for Android, Apple Maps for iPhone if you know they prefer it).
• Posting publicly or unsure of platform? Google Maps is the safest default — it works on every platform and most people recognise it.
• Inside an app that handles geo:? Use the geo:URI — the user's preferred map opens.
• Sending over voice or paper?Use plain text — "forty point seven four eight four, minus seventy-three point nine eight five seven."

What each URL scheme does

The geo: URI (RFC 5870) in detail

Among the eight URLs the tool generates, the geo: URI is the only one defined by an open standard. RFC 5870 describes a simple, platform-neutral way to encode a geographic location as a URI. The minimal form is geo:<lat>,<lon>; optional add-ons include altitude (a third comma-separated number) and a CRS (coordinate reference system) parameter (;crs=wgs84 is the implicit default).

Support is broad on mobile (Android handles geo: natively; iOS started honouring it in 6+), patchy on desktop. Tap a geo:link on a phone and the OS opens the default map app at that coordinate. Tap it in a desktop browser and nothing happens unless a handler is registered (rare). Worth including in any multi-platform share message: it's harmless on desktop and the right call on mobile.

Ten worked examples — Empire State Building at 40.7484, -73.9857

The last two rows aren't generated by default — the universal https://forms cover them already on every platform. They're shown for completeness, since both URL schemes are documented and occasionally useful when you specifically need the native-app fast path on iOS.

Misconceptions worth getting straight

"The same URL works for all map apps"

No. The three big web schemes (Google, Apple, OSM) each have their own grammar; clicking a Google Maps link won't open Apple Maps and vice-versa. The geo:URI is the closest thing to a universal scheme, but it's only reliable on mobile. For cross-platform sharing, send multiple links and let the recipient pick — that's what this tool generates.

"The coordinate is hidden in the URL"

No — every URL the tool produces contains the lat/lon in plain text. That's how the link reproduces the pin to the recipient. If the location is sensitive (a home address, a remote campsite, a private meeting point), think before sharing. Coordinately never receives the coordinate, but every recipient of the URL does.

"Adding a label name puts a custom title on the pin"

Partly. Apple Maps and Bing honour a q= / sp= parameter that can carry a label (q=Empire+State+Building). Google Maps' search?api=1 form does notsupport a custom label — it treats the query as a search term, so passing "Empire State Building" will find the famous landmark rather than your specific coordinate. This tool uses raw coordinates as the label-fallback to keep the behaviour predictable across platforms.

"A shorter URL means a better link"

Shorteners (bit.ly, tinyurl) make URLs cleaner but introduce a third-party hop, a potential rate-limit, and a tracking pixel by default. For sensitive coordinates, raw URLs are preferable — the recipient sees exactly where they're going. For published links (newsletters, social posts) the Google Maps form is short enough that shortening isn't worth the trade-off.

"Map apps round coordinates to the nearest building"

Mostly they don't — the pin lands at the exact lat/lon you encoded, which is often nota building's front door. If you want the recipient to arrive at a doorway, use address-to-coordinates to get the precise address-level coordinate first, then drop the pin there.

When to use which scheme

How to verify a generated URL

Three sanity checks any deep link should pass:

1. Click it in a fresh tab. The pin lands on the coordinate you encoded. If it lands elsewhere, the URL grammar is wrong for the platform.
2. Round-trip the coordinate. Pass the generated URL into /tools/google-maps-coordinates — the extracted lat/lon should match what you started with to six decimal places.
3. Test on the recipient's platform if possible. URL handling differs subtly between iOS Safari, Android Chrome, and desktop. If the recipient platform is critical, verify before mass-sending.

How this tool is built

URL generation is entirely client-side. The widget parses your coordinate input via the shared parseCoordinatePairhelper, then string-templates each URL from the documented platform grammar. No coordinate is sent to Coordinately's servers. The optional nearest-place and elevation lookups in the deep report do hit server-side proxies (Mapbox v6 for nearest place; USGS 3DEP / OpenTopoData for elevation) but those run with Cache-Control: no-store per CLAUDE.md §19.2 and §19.4 — no caching, no logging, no retention.