Google UULE Parameter: Format, Encoding and Limits

What the uule parameter does

Google answers local queries differently depending on where it thinks the searcher is. Normally that comes from the device: browser geolocation, the IP address, the signed-in account. Adding uule= to a google.com/search URL replaces that guess with a place you choose, so a search typed in Lyon can be answered as if it came from Austin.

Google has never published a specification. Everything below comes from decoding values and checking the results they produce, which you can repeat yourself with the snippets on this page. The parameter has been stable for years, but nothing guarantees it will stay that way.

Anatomy of a UULE string

Here is a complete, valid UULE for Austin:

w+CAIQICIaQXVzdGluLFRleGFzLFVuaXRlZCBTdGF0ZXM=

Drop the w+ and base64-decode the rest. You get six bytes of header followed by plain text:

The first five bytes never change: two numeric fields with the values 2 and 32, then the tag announcing a string. Community decoders label those two numbers as a location “role” and “producer”; Google has not confirmed the names, and for building a UULE they are simply constants.

The interesting part is the sixth byte. Base64 turns every 3 bytes into 4 characters, so the 6-byte header becomes exactly 8 characters: CAIQ for 08 02 10, then ICIa for 20 22 1a. That eighth character carries the low six bits of the length byte, and because the name then starts on a clean 3-byte boundary, its base64 can simply be appended. This is why generators describe a UULE as “prefix + key character + base64(name)”. The key is not a checksum or a secret; it is the length, written as one base64 digit.

Two consequences most generators gloss over:

• →The length is in bytes, not characters. “Szekszárd” is 9 characters but 10 bytes in UTF-8, because the accented letter takes two. A generator that counts characters picks the wrong key for every name with an accent.
• →The trick only works below 64 bytes. One base64 digit holds 0 to 63. A longer name changes the character before the key too, so the fixed CAIQICI prefix no longer applies. Canonical names are almost always shorter than that.

You will still find copies of a widely shared example that pairs the Austin name with the key l. Decode it and the length byte reads 37, for a name that is 26 bytes long. Whatever Google does with an inconsistent value like that, it is not the value you meant to send, so check the key before trusting any UULE you copy.

Build and decode one yourself

A few lines of Node.js cover both directions:

const KEY = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_";

function encodeUule(name) {
  const bytes = Buffer.from(name, "utf8");
  if (bytes.length > 63) throw new Error("name too long for the short form");
  return "w+CAIQICI" + KEY[bytes.length] + bytes.toString("base64");
}

function decodeUule(uule) {
  const raw = Buffer.from(uule.slice(2), "base64");
  return { length: raw[5], name: raw.subarray(6).toString("utf8") };
}

Running it on three canonical names gives the values below. Note how the key tracks the byte count. Generators disagree on whether to keep the trailing = padding; the decoded bytes are the same either way.

In a query string the + after w decodes to a space. The value is normally pasted exactly as shown, without encoding it further.

Where the name has to come from

The name is not free text. It has to match a canonical name from Google’s geographic target list, the same list Google Ads uses for location targeting and publishes as a downloadable file. Each row has an ID, a short name, a canonical name, a parent, a country code and a target type: country, state, county, city, postal code, neighborhood, airport and so on.

Canonical names are comma-separated with no space after the commas, run from the smallest place to the country, and use Google’s English spelling: Austin,Texas,United States, not Austin, TX. A space after a comma or a local-language spelling gives you a different string, and a different string is a different (usually unknown) name.

Because postal codes are target types in that list, classic ZIP code rank tracking is exactly this mechanism: one UULE per postal code, one result per ZIP. That is also its ceiling. Google answers for the postal code as a whole, so every business inside it gets a single rank, however large the area. Covering a city properly takes many points, which is what city rank tracking with a grid does.

What happens when Google does not know the name

Nothing visible. There is no error and no warning. Google drops back to a broader place it does recognise, often the country, sometimes a default that has nothing to do with your request, and still returns a perfectly normal-looking page of results.

We hit this in production through the location field of the SERP API Geogrid uses, which takes a place name and passes it to Google as the search location. Some of the cases we logged while testing in September 2026:

• →Le Marais, Paris, France returned plumbers near Lille, about 200 km away.
• →Bottyánhegy, Szekszárd, Magyarország, a neighborhood with its Hungarian names, returned pizzerias in Illinois.
• →The accented Szekszárd, Hungary resolved to Hungary as a whole, while the ASCII Szekszard, Hungary resolved to the town.
• →The same name did not always resolve the same way from one call to the next.

For a rank tracker this is the dangerous failure. A fallback to the wrong city does not look broken; it looks like the business ranks nowhere. If your heatmap is red in an area where the client gets calls every day, a location that silently fell back is the first thing to rule out. Our guide to geo-location rank tracking covers how to spot a tracker reporting the wrong city.

UULE versus coordinates

The short form names a place. It cannot say “this corner of this street”. For that, there are a few other levers, each with its own catch:

The a+ variant is worth a word because it is where the “UULE contains GPS coordinates” idea comes from. It is base64 of a text-format protobuf with a latitude and longitude multiplied by ten million and a radius, the shape Chrome has used to report device location to Google. Whether and how Google honours it when it arrives as a URL parameter is not documented, and we do not rely on it.

Google Maps is a separate case. Maps ranks listings for the area on screen, which the URL expresses as @latitude,longitude,zoom. A Maps rank is therefore a function of a point and a zoom level, not of a place name, and that is the lever that gives point-level resolution. The distinction between the map and the three-pack on web search is covered in Local Pack vs Local Finder.

How to test a UULE

1. 01Decode it first. The length byte must equal the byte length of the name, and the name must match the canonical name exactly.
2. 02Open a private window and block location access for google.com, so your browser does not volunteer its own position. Stay signed out.
3. 03Build the URL: https://www.google.com/search?q=plumber&hl=en&gl=us&uule=… with the language and country that fit the place.
4. 04If Google prints a location at the bottom of the results page, it should name your place, not your own city.
5. 05Check the addresses in the local pack. If they sit in another city, the name fell back, whatever the footer says.
6. 06Run it again later. A name that resolves once and falls back the next time is not one to build a report on.

If all you want is to see where a listing ranks around an address, the free local rank check runs a 3×3 grid of Google Maps checks around it, reading the first page of results at each point, without building any URLs.

How Geogrid sets the search location

A grid needs a different location for every point, often a few hundred metres apart, and the short UULE form cannot express that. So Geogrid sends two things for each point to the Google Maps endpoint of its SERP API:

• →Coordinates and zoom in the Maps format, ll=@lat,lng,zoomz, which set the exact point.
• →A place name in the location field, which sets the region. Coordinates alone were ignored in our tests: the API fell back to its own server location in the United States.

The place name is where the UULE lessons apply. For each point, Geogrid reverse-geocodes the coordinates in English and builds a short list of candidates from most to least precise: city with county and country, city with state and country, city and country in ASCII, the same with accents, and finally the country alone. Neighborhood names are left out, because they were the ones most likely to be unknown.

Then it checks the answer instead of trusting it. If the median distance from the point to the returned listings is more than 25 km (40 or 60 km on wider zoom levels), the next candidate is tried, up to four. The name that worked is remembered for that cell of roughly 1 km and tried first for the rest of the grid and later scans. The retries cost us API calls; a point is still billed as one credit.

On 20 production scans across 13 countries, sending a single location string per point returned local results on 47% of points. With candidate selection and the distance check it was 95%. The remaining points are the honest limit of the approach, and points where the API returns nothing at all are stored as missing data rather than as “not ranked”.

Frequently asked questions