Auto-Detected Regional Pricing — Free HTML CSS JS Snippet

Showing a visitor a locale-correct price the moment a pricing page loads — without a geolocation API call or a server round-trip — is possible using two things the browser already knows: navigator.language and Intl.NumberFormat. This snippet builds a pricing card that reads the visitor's real browser locale, maps it to a plausible region and currency, formats the price correctly for that locale, and gives the visitor a manual override dropdown in case the automatic guess is wrong.

Reading the real locale, not a hardcoded value

detectRegionFromLocale() reads navigator.language directly from the browser — this is the actual language/region tag the visitor's browser reports (e.g. de-DE, en-GB, ja), not a simulated or hardcoded string. A small set of substring checks maps common patterns to one of seven supported regions, defaulting to the US when nothing matches. Because this reads a live browser API, the detected badge genuinely reflects whoever is viewing the page — open it with a browser set to German and it detects Germany; set to Japanese and it detects Japan.

One base price, converted per region

Every region entry in REGION_TABLE pairs a currency code, an Intl-compatible locale string, and a conversion rate. The displayed price is always computed as BASE_USD * entry.rate, rounded, and handed to Intl.NumberFormat(locale, { style: 'currency', currency }) — the same pattern used in Pricing Card Currency Switcher, extended here to seven regions instead of four and driven by automatic detection rather than only manual clicks. Because every conversion originates from the same BASE_USD constant, there's no compounding rounding error from repeatedly converting an already-converted number.

Why the rates are clearly labeled as example rates

The rates in REGION_TABLE are realistic figures a shopper would recognize as plausible, but they are static and will drift from actual market rates over time — the disclaimer beneath the card says so explicitly. A production implementation should fetch current rates from a currency-exchange API on a schedule (hourly or daily is typical for a marketing page) and cache the result, exactly as noted in the currency switcher snippet.

The override exists because detection is a guess, not a fact

navigator.language reflects the browser's configured language, which frequently diverges from the visitor's actual location or preferred billing currency — someone traveling, using a VPN, or simply running their OS in a second language would otherwise be shown a currency they didn't choose. The #rcdRegionSelect dropdown lets them pick "Use detected region" or any of the seven regions directly, and selecting a region re-renders the price using the exact same formatForRegion() function the automatic detection uses — so manual and automatic paths are guaranteed to produce identical, correctly formatted output.

Customizing it

Add more regions to REGION_TABLE, replace the static rates with a fetched exchange-rate feed, or swap navigator.language detection for an IP-geolocation lookup and keep the same override pattern as a fallback. Pair it with Pricing Card Currency Switcher or a Currency Converter elsewhere on the page.