How I Modeled US Lottery Tax Withholding for 21 Countries Without a Backend

autumnbuilds — Thu, 06 Aug 2026 07:03:41 +0000

Every time a US Powerball or Mega Millions jackpot balloons enough to hit global headlines, the advertised number is misleading in a very specific way: it represents the pre-tax annuity total, paid out over 29 years. For anyone living outside the US, finding a straightforward answer to "okay, but what would actually land in my bank account, based on where I live?" is surprisingly hard to come by.

I built ChamTax to answer that question directly. The most interesting engineering challenges here weren't about the UI — they were rooted entirely in modeling the cross-border tax logic.

The shape of the problem

For a non-US resident, winning a US lottery touches at least two distinct tax jurisdictions:

US non-resident withholding — under IRC §871(a), a flat 30% is withheld at the source, before the money ever leaves the US.
Home-country taxation — handled completely differently by every country: flat rates, progressive brackets, surcharges stacked on surcharges, and sometimes an explicit "no confirmed statutory rule" gap.

Most of these interactions also involve a foreign tax credit (FTC): in theory, the US withholding is credited against what you owe at home, up to whichever amount is smaller, so the two taxes don't just stack. In practice, that credit disappears whenever a country has no active tax treaty with the US — then the two taxes simply add up in full.

Client-side only, by design

There's no backend. No database, no user accounts, nothing to leak. All 21 country tax models and all 50 US state rates live as plain JavaScript objects bundled straight into the browser, and every calculation runs 100% client-side.

That was a deliberate constraint, not a limitation I worked around — it eliminates a category of infrastructure cost and attack surface I didn't want to manage solo, and it turns the privacy story into a verifiable fact instead of a policy document.

The trick that made 20 of the 21 countries easy

For almost every supported country, the tax model reduces to one pattern:

function flatCountry(amountUsd, rate, ftcAvailable) {
  const usWithholding = amountUsd * 0.30;
  const homeTax = amountUsd * rate;
  const credit = ftcAvailable ? Math.min(usWithholding, homeTax) : 0;
  const additionalTax = Math.max(homeTax - credit, 0);
  return amountUsd - usWithholding - additionalTax;
}

Because it's a flat percentage of the payout, the math is entirely currency-invariant — I never need a live exchange rate to compute the rate of tax, only to format the final number in whatever currency the user picks. That collapsed what could've been 21 separate currency-conversion code paths into one shared function driven by a per-country { rate, ftcAvailable } config.

Korea: the one branch that needed real money math

South Korea is the exception. It taxes foreign lottery winnings as ordinary income under a progressive bracket system, and the brackets are defined in absolute KRW thresholds — not percentages of the payout.

Because those bracket boundaries are fixed KRW amounts, this branch has to convert the USD payout to KRW first, walk an 8-tier progressive tax table, then convert the result back. It's the only place in the entire engine where the exchange rate actually changes which bracket you land in, rather than just the currency you see on screen.

Being honest about what isn't verified

A handful of countries — Thailand, Sri Lanka, Cambodia, Mongolia, Laos, and Pakistan — don't have a clean, citable rule for how they tax foreign lottery winnings specifically. Their domestic lottery-withholding statutes are written assuming a domestic payer, which a US lottery obviously isn't.

Rather than silently picking a plausible-sounding number, those branches carry an explicit ⚠️ note describing exactly what's being approximated and why (usually the closest general-income statute, or a PwC/KPMG country tax summary), instead of pretending to a confidence the underlying law doesn't support. Getting a tax calculator's confidence-labeling wrong — in either direction, overclaiming certainty or hedging everything into uselessness — felt like the real product risk here, more than any UI decision.

i18n at a scale that made me rethink "just translate it"

The site ships in 26 languages, several of them (Uzbek, Khmer, Sinhala, Kyrgyz) with no native speaker on the team to sanity-check the output. Running everything through one machine-translation pass and calling it done produced a few embarrassing mistakes early on.

What worked better: a second AI pass specifically prompted to flag anything it wasn't confident about, rather than just re-translating. A short list of flagged, low-confidence lines is something you can actually act on — a second uniformly-confident-sounding translation isn't.

What I'd do differently

Going wide on 26 languages before there was meaningful traffic in any single market is the decision I'm least sure about in hindsight. It's the right call if you believe the audience is inherently spread across many countries from day one (which I do, for this specific product) — but it's real, ongoing maintenance weight on every future change to the calculator.

If you're curious about the tax logic for a country I haven't covered here, or think one of the ⚠️-flagged approximations is wrong, I'd genuinely like to hear it — that's the one place in this project where being wrong actually costs someone money.

DEV Community: autumnbuilds