I built a free paycheck calculator because the existing ones annoyed me. Half of them are buried under ad units, and the other half want your email before they will show you a single number. All I wanted was "I make X in this state, what actually lands in my bank account." So I built my own, and then I made the mistake of trying to support all 50 states. Here is what that actually involved.
The live version is at FinanceTool if you want to see where it ended up. This post is about the math and the parts that surprised me.
"Take-home pay" is not one calculation
When you say take-home pay, you are really stacking four separate things:
Federal income tax (progressive brackets)
FICA (Social Security and Medicare, each with their own rules)
State income tax (different brackets, or none at all)
Sometimes local tax (county, city, school district)
The first instinct is to treat tax as "income times a rate." That is wrong, and it is wrong in a way people notice. Brackets are marginal, so each slice of income is taxed at its own rate. Here is the core bracket function. It is boring, and that is the point. Boring and correct beats clever.
type Bracket = { upTo: number; rate: number };
function progressiveTax(taxable: number, brackets: Bracket[]): number {
let tax = 0;
let last = 0;
for (const { upTo, rate } of brackets) {
if (taxable <= last) break;
const slice = Math.min(taxable, upTo) - last;
tax += slice * rate;
last = upTo;
}
return tax;
}
Federal is just this function with the 2025 brackets, after subtracting the standard deduction (15,000 for a single filer in 2025). Nothing exotic yet.
FICA is where the first real edge case lives
Social Security is 6.2 percent, but only up to a wage base that changes every year (176,100 for 2025). Earn a dollar above that and the Social Security piece stops. Medicare is 1.45 percent on everything, plus an extra 0.9 percent on wages above 200,000. So FICA is not a flat 7.65 percent once you climb, and if you hardcode 7.65 you will overcharge high earners.
function fica(wages: number): number {
const SS_WAGE_BASE = 176_100; // 2025
const socialSecurity = Math.min(wages, SS_WAGE_BASE) * 0.062;
const medicare = wages * 0.0145 + Math.max(0, wages - 200_000) * 0.009;
return socialSecurity + medicare;
}
Then you meet the states, and the states are weird
I assumed states would be "federal but with smaller numbers." Some are. Nine have no income tax at all, which is the easy case. The rest each have their own personality, and a few of them genuinely changed how I structured the code.
The one that broke my first design: Oregon and Alabama let you deduct your federal income tax before they calculate state tax. That sounds minor until you realize my state function had no idea what the federal number was. I had been computing federal and state independently, so I had to thread the federal result into the state calculation.
The state signature went from this:
stateTax(taxableIncome, filingStatus)
to passing a context that carries the federal number:
type StateTaxContext = {
grossIncome: number;
filingStatus: FilingStatus;
federalIncomeTax: number; // Oregon and Alabama need this
};
Oregon also caps that federal subtraction (around 8,500, and it adjusts yearly and phases out as income rises), so it is not even a clean "subtract all of it." Alabama lets you take the whole thing. Two states, two rules, one shared context.
A few more that needed real special-casing:
Wisconsin has a sliding standard deduction that shrinks as income goes up, so the deduction is a function of income, not a constant.
Utah does not bracket the way you would expect. It is closer to a flat rate with a taxpayer credit that phases out.
Connecticut phases out a personal exemption with an official table that has hard steps, so you cannot smooth it with a formula. You have to encode the table.
Indiana and Kentucky stack county or local taxes on top of the state rate, so "state tax" is not one number for those.
Ohio, Pennsylvania, and New York City each have local wrinkles too. NYC is basically its own income tax bolted onto New York State.
The spread at the extremes is wider than I expected. North Dakota charges effectively nothing up to about 48,000. Hawaii's top rate is 11 percent and California's reaches 12.3 percent. Same salary, very different paycheck.
How I stored all this without losing my mind
Each state is a config object, and the engine is one pure function. No state-specific branches scattered across the codebase. Adding a state means adding a config and a test, not editing the engine.
type StateConfig = {
code: string;
noIncomeTax?: boolean;
brackets?: Record<FilingStatus, Bracket[]>;
standardDeduction?: (income: number, status: FilingStatus) => number;
deductsFederalTax?: "full" | { cap: number };
computeOverride?: (ctx: StateTaxContext) => number; // for the truly weird ones
};
The genuinely weird states get a computeOverride, and everyone else rides the default path. That kept the special cases contained instead of leaking everywhere.
Testing, because being confidently wrong about someone's paycheck is bad
This is the part I would not skip. For each state I worked out the expected take-home for a known salary by hand, checked it against that state's own 2025 figures, and only then wrote the config. There are about 229 unit tests now, batched per state, running on every change. If a state's number drifts, a test goes red before it ships.
Tax math is one of those domains where "looks about right" is not good enough. People know their own paycheck. If your California number is 200 dollars off, the first Californian who tries it will tell you, loudly.
The bug that passed every server-side check and still broke
Quick war story. The app renders server-side, and my smoke test was "curl every route, assert 200." Green across the board. Then I opened the site in a real browser and the homepage was throwing an error boundary.
The cause: I added two new calculator categories and wired up their labels, but the homepage renders an icon per category from a lookup map, and I had not added icons for the new ones. An undefined icon throws, but only on the client during render. SSR and curl both returned 200 because the HTML streamed fine. The crash only showed up once React hydrated in the browser.
Lesson I will not forget: a 200 from curl does not mean the page works. Client-only render crashes are invisible to SSR and to anything that just checks status codes. The icon lookup has a fallback now, and the category type cannot outrun it.
Where it ended up
It is live, free, no signup, covering all 50 states plus the usual extras like mortgage payoff, retirement, and investing. If you want to poke at the take-home math, it is at financetool.tech. And if you find a state where the number looks wrong, I genuinely want to hear it. That is the kind of bug report that makes this better.
Happy to answer questions about any of the state-specific handling in the comments.
Finance tool which I build