An HTML link to a map location is an ordinary anchor pointing at a map service URL with the place encoded into it.
<a href="https://www.google.com/maps/search/?api=1&query=51.5007%2C-0.1246">
Westminster, London
</a>
There is no map specific HTML. The work is in choosing what identifies the place and encoding it correctly.

Address or coordinates
An address is readable in the source and easy to maintain. It is also a search query, so the map service decides what it means.
For a unique postal address that is fine. For "Acme Coffee, Manchester" it is not, because there may be four of them and the reader gets whichever one ranks first.
Coordinates name one point on the planet. Nothing is inferred, nothing ranks, and the pin lands where you put it.
| What you link | Precision | Readable in source | Good for |
|---|---|---|---|
| Full postal address | Good if unique | Yes | Offices, venues, single sites |
| Coordinates | Exact | No | Entrances, sites, anything ambiguous |
| Place name only | Poor | Yes | Cities and landmarks |
| Saved place identifier | Exact | No | When the service gives you one |
The practical combination is coordinates in the href and the postal address as the visible text. The machine gets precision and the reader gets something they can copy onto an envelope.
Encoding
The same rules as any URL, and the same failure mode when they are ignored.
- Space becomes
%20. - Comma becomes
%2C. - Ampersand in a place name becomes
%26, otherwise it starts a new parameter. - Hash becomes
%23, otherwise the rest of the value is dropped.
A raw space in an href is the usual cause of a map link that searches for half a street name.
Directions rather than a pin
Sometimes the useful action is routing, not looking. Map services accept a destination parameter for that.
<a href="https://www.google.com/maps/dir/?api=1&destination=51.5007%2C-0.1246">
Directions to the venue
</a>
Leave the origin out. The map application fills it from the reader's current position, which is almost always what they want and never something you should guess.
On an event page, offering both is reasonable: one link that shows where it is, one that starts navigation.

The neutral geo scheme
geo: is a scheme for a location without naming a provider.
<a href="geo:51.5007,-0.1246">Open in your map app</a>
On Android this is handed to whichever map application the person uses. On desktop it usually does nothing, and iOS handling is inconsistent.
That makes it a useful secondary link and a poor only link. Offer a normal web map link first, and geo: beside it if your readers are mostly on Android.
Embedding a map
An <iframe> with a map inside works, and costs more than people expect.
It loads third party scripts, it is frequently blocked by a content security policy on corporate networks, and it adds significant weight to a page whose real payload is one address.
There is also the sharing question. An embedded frame will not render at all in an email client, and a page full of frames is not self contained, so it depends on the network at read time.
If the map is the point of the page, embed it. The iframe element covers the attributes. Otherwise link, and put a static image beside the link if you want something visual.
Putting it on a page people actually open
A venue block usually pairs three things: the address, a map link and a phone number.
<address>
12 Example Street<br>London SW1A 1AA<br>
<a href="https://www.google.com/maps/search/?api=1&query=51.5007%2C-0.1246">Open in maps</a><br>
<a href="tel:+442071234567">020 7123 4567</a>
</address>
The <address> element carries meaning for assistive technology, which is the same reasoning as the rest of semantic HTML.
Both links are also printed as text. On a desktop with no map or phone application registered, the reader still has everything they need.

Styling the map link as a button
On an invite, the map link is a primary action and should look like one.
<a href="https://www.google.com/maps/dir/?api=1&destination=51.5007%2C-0.1246"
style="display:inline-block;padding:12px 20px;background:#0f766e;color:#fff;border-radius:8px;text-decoration:none">
Get directions
</a>
Keep it an anchor. HTML button with a link explains why a <button> is the wrong element for navigation.
Make the tap target large. Most people open an invite on a phone while already moving.
Getting the page to the reader
A map link is only useful if the page opens where the reader is, which on an invitation means a phone. Sending an HTML file to a phone does not achieve that; it lands in storage.
Turning the HTML into a link does. In a NOS document the pasted HTML renders as written, with map, phone and mail links intact, and the document has its own address.
Because editing does not move the address, a venue change is one edit rather than a second message to everyone. HTML for event invites covers the rest of that page.
Things that quietly break map links
- Unencoded spaces, which truncate the query at the first word of the street.
- A place name with no city, which resolves to whichever branch ranks highest that week.
- Coordinates in the wrong order. Latitude comes first. Reversed, the pin lands in another country.
- A saved link copied from a signed in session, which may carry account specific parameters that do nothing for anyone else.
- Too many decimal places or too few. Four or five decimal places is street level. Two is a town.
Open the finished link in a private window before sending. That removes your own account, your own history and your own location from the result, which is what every reader will see.