Pricing Currency Switcher — Free HTML CSS JS Snippet

International SaaS pricing pages routinely show prices in a visitor's local currency to reduce the mental friction of converting an unfamiliar figure before deciding to buy — a shopper in Mumbai reads ₹749 far faster than $9.00. This snippet builds a working currency switcher for a three-tier pricing table: a segmented control lets the user pick USD, EUR, GBP, or INR, and every card's displayed price updates simultaneously using a small hardcoded exchange-rate table and locale-correct currency formatting.

Storing one source of truth per plan

Each .plan-card element carries its true price as a data-base-price attribute in US dollars (e.g. data-base-price="29"), which is the single source of truth the switcher always converts *from*, regardless of which currency is currently displayed. This matters because repeatedly converting a previously-converted price (EUR back to GBP, for instance) compounds rounding error — always recomputing from the original USD base avoids that entirely.

A small rate table and Intl.NumberFormat

The RATES object maps each supported currency code to an illustrative conversion rate and an appropriate locale string (en-US, de-DE, en-GB, en-IN). formatPrice() multiplies the USD base by the target rate, rounds to a whole number for clean display, and hands the result to Intl.NumberFormat(locale, { style: 'currency', currency, maximumFractionDigits: 0 }). This single built-in browser API — no library, no manual symbol lookup table — correctly handles everything locale-specific about currency display: the right symbol ($, €, £, ₹), its position relative to the digits (prefix in most locales, but placement and spacing rules genuinely differ), thousands-grouping conventions, and decimal separators. Hardcoding a symbol-and-concatenate approach ('$' + amount) would get every one of those details wrong for at least one of the four supported currencies.

Updating every card at once

Clicking a currency option calls applyCurrency(currency), which iterates every .plan-card, reads its base price, and rewrites the .price-amount text via formatPrice() — all three cards update together in a single pass, so the pricing table never shows a mix of currencies mid-transition. A brief opacity fade (amountEl.style.opacity) on each price during the swap gives a small moment of visual feedback that the numbers actually changed, rather than an instant, easy-to-miss text swap.

The billing disclosure — a small detail with outsized trust impact

Most SaaS billing systems still charge the customer's card in a single base currency (commonly USD) even when the marketing site *displays* prices in the visitor's local currency for convenience — the local-currency figure is an estimate, and the actual charge amount and any bank-side conversion fee depend on the card issuer's own exchange rate at the time of the transaction. Silently showing a EUR price with no clarification about what currency will actually be charged is a subtle trust violation that surfaces painfully at the moment a customer sees an unexpected amount on their statement. This snippet surfaces that reality directly: the disclosure line beneath the pricing grid reads "Prices shown in EUR, billed in USD. Your bank may apply its own conversion rate." whenever a non-USD currency is selected — a small piece of copy that meaningfully improves billing transparency and reduces support tickets and chargebacks from surprised customers.

Why this matters for 2026 trust-driven UX

Transparent, honest pricing disclosure is a core pillar of trust-driven UX: showing a number without the context of what actually gets charged is a dark pattern by omission, even if unintentional. Pairing a genuinely useful convenience feature (localized price display) with an equally visible disclosure about the underlying billing currency is the correct way to implement this pattern — convenience without hidden surprises.