uule Google: How to Simulate a Search From Any City in the World Without a VPN

Paste this URL into any browser — Paris, Singapore, Reykjavík, a cabin in rural Maine — and Google returns Manhattan restaurants:

No VPN, no proxy, no IP manipulation. One URL parameter carries the location and Google's geo-resolver honours it as if the searcher had walked into a coffee shop on Lexington Avenue and pulled out their phone. The parameter is &uule=. Its value looks like a random base64 string, but it's really a short structured message carrying the city's canonical name — pulled straight from the Google Ads geotargets CSV.

Three levers, one winner: gl, hl, and uule

Three Google URL parameters touch locality. Most SEO writing conflates them. They do entirely different jobs.

gl=us tells Google to weight US-hosted and US-authored results more heavily during ranking. It does not relocate the search. A Berlin IP running gl=us still gets German autocomplete, a German Knowledge Panel, and Local Pack entries for Berlin.

hl=en changes the language of the "About X results" text, the filter tab labels, and the Knowledge Panel section headings. It's cosmetic. It does not shift the Local Pack, does not change autocomplete, and does not touch the geo-resolver.

uule=w+CAIQICIf… is the only one of the three that persuades Google the request originates from a specific city. The Local Pack changes. Organic results reshuffle. Autocomplete re-ranks against the target location's query history. gl and hl are blunt knives. uule is the scalpel. The rest of this article is about the scalpel.

What's actually inside &uule=

Strip the literal w+ prefix and you are left with standard base64:

Decode the base64 and you get a short binary message carrying three pieces of information: a version number, a source code, and the city's canonical name as plain text. The binary packaging is a Google-internal format called Protocol Buffers, but nobody has to decode it by hand — the live encoder below handles it.

Two of those three pieces do the heavy lifting. The source code is the value 32, and it tells Google's geo-resolver where to look the name up — in this case, the Google Ads geotargets file. That file is the only location database Google publishes externally, and its presence is what makes the whole trick reproducible. The canonical name is the interesting part: decode the base64 and the last 31 bytes are literally the plain UTF-8 string New York,New York,United States. No obfuscation, no hashing. A city, a state, a country, in the exact comma-separated form the geotargets file dictates.

The Google Ads geotargets CSV

The canonical names that go into a uule come from a single authoritative file: the Google Ads geotargets CSV. Google currently publishes it at developers.google.com/google-ads/api/data/geotargets and regenerates it roughly every quarter. Both the CSV filename and the documentation path itself rotate over time — if the link above drifts during a Google docs reorganisation, a search for "Google Ads API geotargets" points to the current page. Fetch the freshest CSV before relying on specific rows.

The CSV has seven columns: Criteria ID, Name, Canonical Name, Parent ID, Country Code, Target Type, Status. The one that goes into a uule is Canonical Name, not Name. That distinction is where most hand-rolled uules silently fail:

• Name = New York — does not resolve.
• Canonical Name = New York,New York,United States — resolves to the city.

Three sample rows from a recent download, trimmed to the interesting columns:

Always filter for Status = Active. Decommissioned rows remain in the file for historical reference, but Google's geo-resolver no longer accepts them — a stale canonical produces a silently ignored uule and a SERP that looks "close enough" to fool a careless eye. Criteria IDs also rotate as Google regenerates the CSV, so copy fresh values rather than trusting an ID you memorised last year.

How the encoder works

Three steps, all handled client-side by the encoder below. Start typing a city name in the canonical field — the encoder pulls matching rows from the live geotargets CSV so nothing about the comma-separated format has to be memorised. Pick a row, edit the query, then hit the button to open the resulting search in a new tab.

1. 1. Look up the canonical name in the geotargets CSV. Example: New York,New York,United States
2. 2. Wrap it in the binary envelope — version 2, source code 32, then the canonical name as UTF-8 bytes.
3. 3. Base64-encode the result and prepend w+. That final string is the uule.

Verification: how to know it actually worked

Generating a uule and running a query proves nothing on its own. Google's geo-resolver silently ignores a uule that fails to parse, and the fallback SERP often looks "approximately right" to someone who wasn't expecting anything different. Three verification methods, ranked by reliability.

Comparative A/B SERP test (most reliable)

Run the same query with two uule values that should produce meaningfully different Local Packs. best ramen with the NYC uule surfaces Ippudo, Totto, and Jin Ramen. Swap the canonical for London,England,United Kingdom in the encoder above and the same query surfaces Shoryu, Kanada-Ya, and Bone Daddies instead. The Local Pack is a different continent. If the two result sets are identical or near-identical, the uule is being ignored and the canonical name needs a character-by-character check against the CSV.

The "Results for" banner (unreliable on its own)

Google sometimes renders a Results for [city] banner above the SERP. When it appears, the uule is being honoured. When it doesn't appear, the uule may still be working — the banner is a UI decision, not a protocol-level status signal. Treat its presence as positive evidence and its absence as no information at all.

The authenticated session trap

Search while signed into a Google account and the account's own location history can override uule= for some query classes — particularly Knowledge Panel queries and anything that triggers personalised results. A logged-in test can silently contradict a logged-out test on the identical URL. For pure location-shifted SERPs, always use an incognito window and a session with no Google sign-in.

Limits and edge cases

The parameter works, but not everywhere and not forever. The honest constraints:

• Canonical names must match byte for byte. Diacritics, commas, capitalisation, whitespace. São Paulo,São Paulo,Brazil and Sao Paulo,Sao Paulo,Brazil are different values, and only the first one exists in the CSV. Paraphrasing will not resolve.
• Only Google Ads geotargets entries work. Google's geo-resolver has other internal location sources — business listings, postal code tables — but their contents aren't published externally, and nothing besides a geotargets canonical will reach them from a URL.
• There is a second uule format, and it isn't the one this article covers. A few Google responses set a UULE cookie whose value starts with a+ — that's a different legacy format and not interchangeable with the w+ URL parameter covered here.
• Google reserves the right to ignore uule. Queries classified as financial, medical, or governmental are often served from the user's real region regardless of parameters — a compliance choice, not a bug. Test the exact query that matters before relying on uule in a production workflow. The full operator reference has the other levers if this one is locked down for a particular category.
• Coordinate uule with gl when verticals matter. For standard organic SERPs gl never reaches the geo-resolver and the two parameters stay independent. Verticals like Google News and Google Shopping are less forgiving — pinning uule to a city in one country while gl points at another can return mixed publisher languages, empty Top Stories blocks, or non-local product listings. When an audit touches those verticals, set gl to the country code from the same CSV row the canonical came from.
• Stability is empirical, not promised. The parameter has been stable for roughly a decade, but it is undocumented. A future Google index pipeline change could deprecate it without notice. Treat uule as a tactic, not as infrastructure.

Takeaways

Two things to carry out of this article. uule= is the only URL parameter that shifts Google's location signal at city granularity — gl and hl don't touch the geo-resolver at all. And the canonical name from the geotargets CSV is the only string that resolves, exactly as it appears in the file.

The workload that earns the setup cost is a comparative SERP audit across regions — running the same query with two uule values and reading the delta. One-off "what does this query look like in Tokyo" lookups are cheaper to answer by asking a colleague in Tokyo. Everything in between is where a fast, accurate uule generator pays for itself several times a week.