The New <geolocation> Element: Ending Permission Spam?

Hello World. 👋

Remember the wild days when we did browser sniffing to find out if we could use a feature? Well, it’s not quite that bad today, but handling location data on the web has been… let’s say “suboptimal” so far.

Everyone knows it: You open a site, the content is just loading, and BAM – a popup flies in your face: “www.something.com wants to know your location”. Reflexive reaction? Block. And just like that, the feature is dead forever, even if we actually needed it later.

With Chrome 144 (yes, we’ve come that far), the new <geolocation> HTML element is arriving to solve exactly this problem.¹ I’ve taken a look at it – without the hype, but with a cup of coffee.

What is the <geolocation> element?

In short: It’s a dedicated button rendered by the browser that explicitly asks the user if they want to share their location. Instead of firing off imperatively with JavaScript (navigator.geolocation.getCurrentPosition()) and hoping for a permission on a whim, we’re building in a native element.²

This looks charmingly simple in code:

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

<script>
  function handleLocation(event) {
    if (event.target.position) {
      const { latitude, longitude } = event.target.position.coords;
      console.log("Here I am:", latitude, longitude);
    }
  }
</script>

Features at a Glance

• Declarative instead of Imperative: We tell the browser “location input could happen here” instead of forcing it via script.
• Browser-Controlled UI: The button is styled by the browser (with styling restrictions to prevent abuse). This creates trust because it looks like system UI.
• Autolocate: With the autolocate attribute, the element can retrieve the location on load – but only if permission was granted previously.¹
• Permission & Data in One: If the user clicks, the browser asks for permission (if necessary) and delivers the data. One smooth process.

Why this is (IMO) a Step in the Right Direction

As someone who has been around since 2001, I’ve seen many APIs come and go. I like this approach for two reasons:

1. UX Hygiene: It prevents classic layout shift or “permission bombing” on page start. The user must interact (click) for the query to start. That’s clean design.
2. Security & Trust: Since the browser retains control over the look and text of the button (e.g., a map pin icon and text like “Use location”), phishing becomes harder. No one can build a “Win a free iPhone” button that secretly grabs GPS data in the background.

The concept strongly reminds me of <input type="file">. While that’s as ugly as a night in November and hard to style, everyone knows: “If I click here, I’m uploading a file.” The <geolocation> element tries to establish exactly this mental connection for location data.

The Catch

Of course, there’s a catch. This is the web; nothing is simple.

Currently, we’re talking about a feature that’s primarily available in Chrome 144+.² Mozilla and WebKit (Apple) have sent positive signals, but until this works across all browsers, a lot of water will flow down the Rhine.

For us developers, this means (once again): Progressive Enhancement. We build in the <geolocation> element but check first if it exists. If not, we fallback to the good old JavaScript API. It’s a bit like it was back then with rounded corners – first only for the cool kids, later for everyone.

Conclusion

The <geolocation> element is a sensible evolution. It takes the responsibility for permission UI away from developers and gives control back to users. It will significantly reduce JavaScript spaghetti code for permission queries.

Will we be able to use it everywhere immediately? No. Should we have it on our radar? Definitely. It’s a small puzzle piece for a more privacy-friendly web, and I fully support that.

Stay curious and stay critical! ✌️

Footnotes

1. Introducing the <geolocation> HTML element | Blog - Chrome for Developers, accessed February 9, 2026, https://developer.chrome.com/blog/geolocation-html-element ↩ ↩²

2. The <geolocation> element | Chrome Platform Status, accessed February 9, 2026, https://chromestatus.com/feature/5125006551416832 ↩ ↩²