This post covers what I learned: how I structure the calculation logic in TypeScript, how I think about calculator state, why I designed for phones first, and the SEO lessons I'd tell anyone shipping a React + Vite site that needs to be found.

Live demo: salarypaytools.com

Why React + Vite + TypeScript

A calculator site is mostly forms and instant feedback. React fits that well, and Vite keeps the dev loop fast: the dev server starts in a moment and hot reload doesn't get in the way when you are tweaking inputs fifty times an hour.

TypeScript was the most important choice. Pay math has many values that are all just number: hourly rates, hours per week, weeks per year, annual totals, percentages. Mixing them up is easy. Named types and small pure functions make those mistakes much harder to write.

Keep the math pure and boring

My rule is that the math lives in plain functions with no React in them. Components gather input and display output. The functions do the arithmetic, and I can test them in isolation.

Here is the core of hourly to annual conversion:

export interface HourlyInput {
  hourlyRate: number;     // dollars per hour
  hoursPerWeek: number;   // regular hours, e.g. 40
  weeksPerYear: number;   // paid weeks, e.g. 52
  overtimeHoursPerWeek?: number;
  overtimeMultiplier?: number; // 1.5 is the common case
}

export interface PayBreakdown {
  annual: number;
  monthly: number;
  biweekly: number;
  weekly: number;
}

const round2 = (n: number) => Math.round(n * 100) / 100;

export function hourlyToAnnual(input: HourlyInput): PayBreakdown {
  const {
    hourlyRate,
    hoursPerWeek,
    weeksPerYear,
    overtimeHoursPerWeek = 0,
    overtimeMultiplier = 1.5,
  } = input;

  const weekly =
    hourlyRate * hoursPerWeek +
    hourlyRate * overtimeMultiplier * overtimeHoursPerWeek;

  const annual = weekly * weeksPerYear;

  return {
    annual: round2(annual),
    monthly: round2(annual / 12),
    biweekly: round2(annual / 26),
    weekly: round2(weekly),
  };
}

With the usual full-time assumptions (40 hours a week, 52 weeks), $25 an hour comes out to $1,000 a week and $52,000 a year. That 2,080-hour year is a convention, not a law of nature, so I keep weeks per year as an input. Someone with two unpaid weeks off should be able to say so.

Two habits that saved me bugs:

1. Derive everything from one source. Monthly and biweekly come from the annual figure. They are never calculated separately, so they can't drift apart.
2. Round only at the edges. Keep full precision through the math and round for display. Rounding in the middle adds up to visible cent errors.

A simplified FICA calculation

The take-home side starts with payroll taxes. For an employee, FICA is two parts:

• Social Security: 6.2% of wages, up to an annual wage cap (the Social Security wage base). The cap changes every year. It is $176,100 for 2025 and $184,500 for 2026.
• Medicare: 1.45% of all wages, with no cap.

const SOCIAL_SECURITY_RATE = 0.062;
const MEDICARE_RATE = 0.0145;

// Update every year from the SSA's published wage base.
const SOCIAL_SECURITY_WAGE_BASE: Record<number, number> = {
  2025: 176_100,
  2026: 184_500,
};

export function employeeFica(annualWages: number, year: number) {
  const wageBase = SOCIAL_SECURITY_WAGE_BASE[year];
  if (wageBase === undefined) {
    throw new Error(`No Social Security wage base configured for ${year}`);
  }

  const socialSecurity =
    Math.min(annualWages, wageBase) * SOCIAL_SECURITY_RATE;
  const medicare = annualWages * MEDICARE_RATE;

  return {
    socialSecurity: round2(socialSecurity),
    medicare: round2(medicare),
    total: round2(socialSecurity + medicare),
  };
}

For $52,000 in wages that is $3,224 of Social Security plus $754 of Medicare, $3,978 in total, which is the familiar 7.65%. Above the wage base, the effective rate drops because Social Security stops.

The caveat. This is simplified on purpose. It leaves out the Additional Medicare Tax: an extra 0.9% that employers must withhold on wages above $200,000 in a calendar year. The final liability depends on filing status, so withholding and what you actually owe can differ. It also assumes a single job. With two employers, each one withholds Social Security up to the cap on its own, and the excess comes back when you file. And it ignores pre-tax deductions, such as some retirement and health contributions, that can change which wages are taxed.

I throw an error for an unknown year instead of quietly reusing an old cap. A wrong number that looks right is the worst result a pay calculator can give. In the UI, take-home results are labelled as estimates, and they currently cover only a few states (Texas, Arkansas, Illinois, and North Carolina) because each state's rules need their own care.

State that survives a refresh

Losing your numbers on refresh, or when you switch tabs on a phone, feels broken. There are a few layers to think about. I'm describing the pattern here, not claiming every page of my site does all of it today:

• URL query params for the main inputs (?rate=25&hours=40). Results become shareable and bookmarkable, and the back button works.
• sessionStorage for in-progress values that don't belong in a URL. They survive a reload in the same tab and are gone when the tab closes, which suits a privacy-minded tool.
• localStorage only for real preferences you'd want next week.

A minimal hook for the URL layer:

import { useCallback, useState } from "react";

export function useQueryNumber(key: string, fallback: number) {
  const read = () => {
    const raw = new URLSearchParams(window.location.search).get(key);
    const n = raw === null ? NaN : Number(raw);
    return Number.isFinite(n) ? n : fallback;
  };

  const [value, setValue] = useState<number>(read);

  const update = useCallback(
    (next: number) => {
      setValue(next);
      const params = new URLSearchParams(window.location.search);
      params.set(key, String(next));
      window.history.replaceState(null, "", `?${params}`);
    },
    [key]
  );

  return [value, update] as const;
}

replaceState instead of pushState matters. Otherwise every keystroke adds a history entry, and the back button becomes useless.

Mobile-first, because that's where people are

Many people check a pay number on a phone, often while looking at a job listing. So I designed for small screens first:

• inputMode="decimal" on number fields, so phones show the numeric keypad.
• Big tap targets and labels above the inputs, not tiny placeholders that disappear.
• Results update as you type, so there is no "Calculate" button to hunt for.
• The key result goes at the top in large type, with the breakdown below it.

A plain CSS grid that becomes multi-column at wider widths did more for usability than any component library would have.

SEO lessons from a client-rendered SPA

This is where I learned the most. A default Vite React build ships an almost empty index.html and renders everything in JavaScript. Crawlers can run JavaScript, but you are relying on that going well, and social preview scrapers often don't run it at all. What helped:

1. Prerender every route. Each calculator page is generated as real HTML at build time and then hydrated. Today each route on the site serves its own static HTML with its own <title>, so a crawler sees real content on the first request.
2. Unique tags per page. Each route gets its own title, meta description, canonical URL, and Open Graph tags. Twenty pages that all say "Salary Calculator" compete with each other.
3. A sitemap and robots.txt. The site has an XML sitemap listing every calculator and guide, referenced from robots.txt and submitted in Search Console. It is boring, and it helps.
4. Consistent URLs. I use trailing slashes everywhere, in links, canonicals, and the sitemap, so the same page doesn't show up under two addresses.
5. Content, not just widgets. A calculator alone is thin. A short explanation of the assumptions under each tool helps users and gives search engines something to understand.

What's next

More state coverage for take-home pay, tests that pin the tax tables to each year's published figures, and more of the state patterns above on every page. If you're building something similar, my one piece of advice: keep the math pure, put the yearly constants where you can't forget them, and prerender from day one.

You can try the calculators at salarypaytools.com. I'd love feedback, especially on the math, from anyone who has built payroll tools.

You have two offers. One says "$62,000 a year." The other says "$28 an hour." Which pays more?

The quick trick is to multiply the hourly rate by 2,080 (40 hours × 52 weeks). That turns $28 an hour into $58,240, so the salary looks like the winner. But that number leaves out most of what decides how much a job is really worth: how many hours you'll actually work, whether you get paid for the extra ones, how much paid time off you get, and what the benefits cost you.

This guide walks through each of those, then compares two concrete offers with the math shown.

Start with classification: exempt vs nonexempt

In the US, the federal Fair Labor Standards Act (FLSA) splits most employees into two groups:

• Nonexempt employees must be paid overtime, at least 1.5 times their regular rate, for every hour worked over 40 in a workweek.
• Exempt employees are not owed overtime under federal law. To be exempt, a job generally has to pass a salary test and a duties test (executive, administrative, professional and a few other categories).

Two common myths are worth clearing up:

1. "Salaried" does not automatically mean "exempt." Some salaried employees are nonexempt and still earn overtime.
2. "Hourly" almost always means nonexempt. If you're paid by the hour, extra hours usually mean extra pay.

Some states add their own rules on top of federal law. California, for example, has daily overtime. So check your state's rules too. If an offer letter doesn't say whether the role is exempt, ask. It changes how you should value every extra hour.

The five things to compare

1. Hours you'll actually work

A salary is a fixed amount for however many hours the job takes. If the role routinely runs 45 or 50 hours a week, your real hourly rate drops. Ask the hiring manager, or better, someone already on the team, what a normal week looks like and how often "crunch" happens.

2. Overtime

For a nonexempt hourly job, overtime can add real money. But it's rarely guaranteed. Count on overtime only if it's steady and predictable. Then run the numbers both with and without it.

3. Unpaid hours

These are the hours that quietly shrink your pay:

• Salaried exempt: evening emails, weekend deploys, on-call weeks. None of it adds a dollar.
• Hourly: an unpaid 30-minute lunch means you're at work 8.5 hours for 8 hours of pay. Under the FLSA, nonexempt employees must be paid for all time worked, including work done "off the clock." Still, ask how the company handles things like shift handovers and required training.

4. Paid time off and holidays

PTO is pay for hours you don't work. Two weeks off versus five is a big difference in your effective hourly rate, even when the yearly pay is the same. Ask how many PTO days and paid holidays you get, and whether sick days are counted separately.

5. Benefits

Health insurance premiums, retirement matching, and other perks can swing an offer by thousands of dollars. Look at what you pay each month for health coverage and how much the employer adds to your retirement account (and what you must put in to get it).

A worked example: Offer A vs Offer B

Here are two made-up but realistic offers. All numbers are for illustration only.

Offer A: Salaried, exempt

• $62,000 per year
• The team says a typical week is about 45 hours
• 15 PTO days + 10 paid holidays (25 days = 5 weeks off)
• 401(k) match of 4% of salary, if you contribute at least 4%
• Your health premium: $150 per month

Offer B: Hourly, nonexempt

• $28 per hour, 40-hour schedule
• About 150 overtime hours a year (roughly 3 a week), based on what current staff say
• 10 PTO days + 5 paid holidays (15 days = 3 weeks off), paid at 8 hours a day
• No retirement match
• Your health premium: $300 per month

Step 1: Gross pay

Offer A: $62,000.

Offer B:

• Base pay: $28 × 2,080 hours = $58,240 (this already includes the paid PTO and holiday hours)
• Overtime rate: $28 × 1.5 = $42 per hour
• Overtime pay: 150 × $42 = $6,300
• Total: $58,240 + $6,300 = $64,540

On gross pay alone, Offer B is ahead by $2,540.

Step 2: Hours actually worked

Offer A: 52 weeks − 5 weeks off = 47 working weeks. 47 × 45 hours = 2,115 hours.

Offer B: 2,080 paid hours − 120 PTO and holiday hours (15 days × 8) = 1,960 regular hours worked. Add 150 overtime hours for a total of 2,110 hours.

Both jobs ask for almost the same time each year.

Step 3: Effective hourly rate (pay only)

• Offer A: $62,000 ÷ 2,115 = $29.31 per hour
• Offer B: $64,540 ÷ 2,110 = $30.59 per hour

Offer B still leads.

Step 4: Add benefits

Offer A:

• 401(k) match: 4% × $62,000 = +$2,480
• Health premiums: $150 × 12 = −$1,800
• Total value: $62,000 + $2,480 − $1,800 = $62,680

Offer B:

• No match
• Health premiums: $300 × 12 = −$3,600
• Total value: $64,540 − $3,600 = $60,940

Now divide by hours worked:

• Offer A: $62,680 ÷ 2,115 = $29.64 per hour
• Offer B: $60,940 ÷ 2,110 = $28.88 per hour

The result flips. Once benefits are counted, Offer A is worth $1,740 more a year, even though its salary looked lower than Offer B's pay with overtime.

Step 5: Test your assumptions

The answer depends on two guesses, so stress-test both.

What if Offer A's "45 hours" is really 50? 47 weeks × 50 hours = 2,350 hours. Then $62,680 ÷ 2,350 = $26.67 per hour. Offer A falls well behind.

What if Offer B's overtime dries up?

• Total value: $58,240 − $3,600 = $54,640
• Hours worked: 1,960
• $54,640 ÷ 1,960 = $27.88 per hour

So the real question is which risk you'd rather carry. With Offer A, you risk long hours for no extra pay. With Offer B, you risk losing overtime you were counting on. Your answer depends on the team, the manager, and how much your evenings matter to you.

A simple checklist before you decide

1. Ask whether the role is exempt or nonexempt.
2. Get a realistic weekly hours estimate from someone on the team.
3. Count PTO and paid holidays in hours.
4. Only count overtime you're fairly sure of, and run a no-overtime version too.
5. Add the employer's retirement match (only if you'll contribute enough to get it), and subtract your premiums.
6. Divide total value by hours actually worked.
7. Do it twice: once with your best guess and once with a pessimistic guess.

If you'd rather not do the conversions by hand, I built a free hourly to salary calculator on SalaryPayTools that handles the basic salary and hourly math. Then plug in your own PTO, overtime and benefits numbers from the steps above.

One last note on taxes

Everything above compares pre-tax value. What lands in your bank account depends on federal income tax, Social Security and Medicare, any state and local taxes, and your own choices, like how much you put into a 401(k) or health plan. If two offers are in different states, compare the take-home pay too, not just the gross. For anything close, a tax professional can tell you exactly how your situation works out.

The biggest lesson from the example is simple: an offer is a rate per hour of your life, not a number on a letter. Compare the hours, the time off and the benefits, and the "obvious" choice is often the other one.