Skip to main content
When your application serves users across different countries and languages, returning globally-ranked results for every query is rarely what those users need. The Custom Search JSON API gives you four complementary parameters — lr, gl, cr, and hl — that work together to bias results toward a specific language, privilege a particular country’s content, restrict results to documents from a given region, and localize Google’s own UI strings. This guide explains what each parameter does, when to use it, how to combine them, and provides reference tables of the most common values.

The four localization parameters

gl and cr sound similar but behave differently. gl is a soft bias — it improves relevance for users in that country without excluding results from elsewhere. cr is a hard filter — it only returns results hosted in the specified country. For most applications, gl alone is the right choice. Use cr only when you specifically need to exclude non-regional results.

lr — Language Restrict

The lr parameter limits results to pages written in the specified language. Values use the format lang_ followed by an ISO 639-1 language code.

Common lr values

You can specify multiple languages by repeating the lr value with pipe-separated entries — e.g., lr=lang_en|lang_fr to include both English and French results. Some clients require URL-encoding the pipe character as %7C.

gl — Geolocation (Country Bias)

The gl parameter biases results toward a specific country without hard-filtering. It accepts a two-letter ISO 3166-1 alpha-2 country code in lowercase.

Common gl values

cr — Country Restrict

The cr parameter hard-restricts results to documents originating from a specific country. Values use the format country followed by an ISO 3166-1 alpha-2 country code in uppercase.

Common cr values

Using cr can significantly reduce result counts, especially for niche queries where little content is hosted in the specified country. Prefer gl unless you have a specific requirement to exclude non-regional results entirely.

hl — Host Language

The hl parameter sets the language of Google’s interface strings — such as the text in the context.title field and metadata annotations in the response. It does not filter result content. Use it to match the language of your application’s UI.
The hl parameter accepts standard ISO 639-1 language codes without the lang_ prefix — e.g., hl=de for German, hl=ja for Japanese.

Combining parameters for a fully localized experience

The real power of these parameters comes from combining them. Here is the recommended combination for a fully localized search experience:
For example, to build a Spanish-language search experience for users in Mexico:

Detecting user locale automatically

Instead of hardcoding a locale, detect it from the browser or HTTP headers and map it to the correct API parameters:
navigator.language reflects the user’s browser language preference, not necessarily their physical location. For location-based biasing, consider pairing this with a geolocation API (with user permission) to set gl more accurately.

Locale combination recipes

These ready-to-use configurations cover the most common localization scenarios:
Standard English results biased toward US sources and audiences.

Quick-reference: gl vs lr vs cr

Setting only gl biases results toward the specified country’s relevance signals — popular domains in that country, local TLDs, etc. — but does not restrict the language of result pages. You may still get mixed-language results. Pair gl with lr to ensure results are both regionally relevant and in the correct language.
Setting only lr filters results by the language of the page content, but does not bias toward any country. A lr=lang_es query without gl may return Spanish-language pages from any country (Spain, Mexico, Argentina, etc.). This is appropriate if you want all Spanish content regardless of origin.
Yes, but use them carefully. gl biases toward a country; cr hard-restricts to it. Using both is redundant for most use cases. However, if you need results exclusively from a country’s hosted pages (via cr) but also want Google’s ranking to favor local relevance signals (via gl), combining them is valid.
No. hl only changes the language of Google’s interface strings in the response metadata (e.g., context.title). It does not affect which results are included or their language. Use lr to control result language.

Next steps

Build a Search App

Wire localization into a complete end-to-end application with a search input and result rendering.

Safe Search

Combine localization with SafeSearch filtering for a safe, region-appropriate experience.

Pagination

Page through localized results using the start parameter.

API Reference

See the full parameter reference for all localization and filtering options.