The New HTML Geolocation Element

If you’ve ever wired up navigator.geolocation.getCurrentPosition(), you know the routine: write the callback, handle the error, manage permission state, and hope the browser doesn’t silently swallow the prompt because the user dismissed it one too many times. The new <geolocation> HTML element takes a different approach entirely—declarative geolocation in HTML, handled by the browser itself.

Here’s what it is, how it works, and what you need to know before using it.

What Is the <geolocation> HTML Element?

The <geolocation> HTML element is an experimental browser-controlled button that lets users share their location directly from the page. Instead of your JavaScript triggering a permission prompt, the user activates the control themselves. The browser handles the permission flow, and you listen for the result.

It shipped in Chrome 144. As of early 2026, this remains a Chromium-led feature and has not yet been implemented in other engines. Treat it as something to experiment with, not ship universally without a fallback. You can track current implementation status on https://caniuse.com/mdn-html_elements_geolocation.

The Problem with the Geolocation API

The navigator.geolocation API is imperative. Your script calls getCurrentPosition(), the browser decides whether to show a prompt, and if the user has dismissed that prompt multiple times, Chrome may quietly block it for a period of time. No error, no feedback—just silence.

The context gap makes it worse. A prompt that appears without explanation gets denied reflexively. That denial can become sticky, and there’s no obvious way for users to undo it.

How Declarative Geolocation in HTML Solves This

The <geolocation> element flips the model. The user clicks the button. That click is the permission signal. The browser knows the request came from a deliberate user action, which helps avoid quiet-block scenarios and gives users a clearer recovery path if they previously denied access.

The HTMLGeolocationElement interface exposes the result directly on the element:

<geolocation onlocation="handleLocation(event)"></geolocation>

function handleLocation(event) {
  if (event.target.position) {
    const { latitude, longitude } = event.target.position.coords;
    console.log(latitude, longitude);
  } else if (event.target.error) {
    console.error(event.target.error.message);
  }
}

The element exposes position and error properties, and you listen for events such as location when the browser returns a result.

Key Attributes

• autolocate — If permission was previously granted, fires the location event on page load without requiring a click. Does nothing if permission hasn’t been granted yet.
• watch — Mirrors watchPosition(), firing continuously as the device moves.
• accuracymode — Accepts "precise" or "approximate". Precise mode maps to enableHighAccuracy: true and changes the button icon to a crosshair. Note that on desktops the difference is often negligible—test on a mobile device outdoors to see real variation.

One quirk worth knowing: you can only use up to three <geolocation> elements per page. Exceed that and all of them stop working.

The element still relies on the same underlying security model as the Geolocation API, which requires a secure context (HTTPS) and explicit user permission.

Geolocation API vs HTML Geolocation Element: Which Should You Use?

Right now, both. The <geolocation> HTML element doesn’t replace navigator.geolocation—it wraps it. Use the element where supported, and fall back gracefully:

<geolocation onlocation="updateMap()">
  <!-- Rendered only in browsers that don't support <geolocation> -->
  <button onclick="navigator.geolocation.getCurrentPosition(updateMap)">
    Use my location
  </button>
</geolocation>

Supporting browsers suppress the child content. Non-supporting browsers render the fallback button. If you want a more automated approach, there’s a polyfill on npm that swaps in a custom element backed by the standard API.

Feature detection is straightforward:

if ('HTMLGeolocationElement' in window) {
  // element supported
} else {
  // use navigator.geolocation
}

Styling Has Hard Limits

The element looks like a button but doesn’t behave like one from a CSS perspective. The browser enforces constraints to prevent deceptive patterns: opacity is locked at 1, contrast between text and background must be at least 3:1, and distorting transforms are blocked. If contrast or font size falls below the minimum threshold, the button doesn’t deactivate visually—it just stops working. You can use the :granted pseudo-class to style the button after permission is granted.

Where This Is Headed

The <geolocation> element is the first in a planned series of capability-specific elements. A <usermedia> element for camera and microphone access is already in origin trial. The pattern—declarative, user-initiated, browser-mediated—is clearly the direction the platform is moving.

Conclusion

The <geolocation> element represents a meaningful shift in how browsers handle sensitive permissions. By moving the trigger from script to user action, it sidesteps many of the quiet-blocking pitfalls of the imperative API and gives users clearer control over when and whether they share their location. Browser support is still narrow, but the fallback pattern is clean and the API surface is minimal. Start experimenting with progressive enhancement today—the permission UX is genuinely better for users, and the declarative model is where the web platform is headed.

FAQs

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.