DEV Community: Muzammil Hussain

Arizona has no tax brackets: modelling a withholding rate the employee chooses

Muzammil Hussain — Thu, 05 Nov 2026 04:32:38 +0000

I keep a paycheck calculator that supports 37 US states. Every state I had added before Arizona had a formula: a flat rate after allowances, or brackets with a standard deduction. Arizona has neither for withholding. The employee fills in Form A-4 and picks a percentage of gross taxable wages: 0.5%, 1.0%, 1.5%, 2.0%, 2.5%, 3.0% or 3.5%. Pick zero if you expect no Arizona tax. Optionally add a fixed dollar amount per paycheck. If you never hand in the form, the employer withholds 2.0%.

That is a different shape of problem. The rate is an input, not a rule, and the input may be missing.

The data model

My engine describes each state as a plain object. Flat states already had rate, so Arizona is a flat state with two extra flags.

arizona: { name: 'Arizona', kind: 'flat', rate: 0.02, azElect: true,
           noDeduction: true, employee: [] }

rate holds the default for the "no form on file" case. The calculation takes the elected percentage when there is one:

const pct = (s.azElect && allowances.pct != null) ? allowances.pct : s.rate;
incomeTax = taxable * pct;
if (s.azElect) incomeTax += allowances.dollar || 0;   // extra dollars per paycheck

The page form is a select with the seven percentages plus zero, and it defaults to 2.0% to match what an employer does without the form.

The zero trap

The first version I wrote was allowances.pct || s.rate. It is wrong in the one case where the user is making a deliberate choice: zero. 0 || 0.02 is 0.02, so a person who certifies they owe no Arizona tax would see 2% withheld.

The fix is to test for "not provided", not for "falsy":

pct: (v.azPct === undefined || v.azPct === '' || v.azPct === null) ? null : Number(v.azPct) / 100

Missing means null and falls back to the default. A real 0 stays 0. This is the same bug class as treating 0 as an absent quantity or an empty discount, and it hides well because the default case looks right.

Tests

I wrote the cases alongside the engine change, with hand arithmetic on a $2,000 paycheck:

Case	Expected Arizona tax
No election (default)	$40.00 (2.0%)
3.5%	$70.00
0%	$0.00
1.0% plus $5 extra	$25.00

near(stateWithholding('arizona', { gross: 2000, periods: 26 }).incomeTax, 40);
near(stateWithholding('arizona', { gross: 2000, periods: 26, allowances: { pct: 0.035 } }).incomeTax, 70);
near(stateWithholding('arizona', { gross: 2000, periods: 26, allowances: { pct: 0 } }).incomeTax, 0);
near(stateWithholding('arizona', { gross: 2000, periods: 26, allowances: { pct: 0.01, dollar: 5 } }).incomeTax, 25);

The page copy is generated from the same engine, and each worked example is asserted against a separate hand calculation before it is written. On $60,000 paid every two weeks, the gross check is $2,307.69, so the default gives $46.15 of Arizona withholding and 3.0% gives $69.23. I also loaded the live page and switched the select to 3.0%: take-home moved from $1,892.00 to $1,868.92, which is the same figure as the table on the page.

Withholding is not the tax

For 2026 Arizona's income tax rate is a flat 2.5% of taxable income (this is what several tax guides and AARP's Arizona page state; I did not open the state's own rate page). Withholding at the 2.0% default is therefore an advance payment against a different number. The final tax is worked out on the return, after deductions and credits, so withholding 2.5% of gross is not a perfect match either.

I did not try to model the return. The page shows what each form choice does to the paycheck and says plainly that the bill is settled at filing. If a calculator hides the gap between the amount withheld and the amount owed, users will treat the first as the second.

Where the data came from

The state's own site answers automated requests with a Cloudflare challenge, and I did not try to get around it. The text of Form A-4 is also published as a PDF on a university HR site, so I read the official form from there and cross-checked the range and the default against PaycheckCity's explanation. For the minimum wage on the same page I used the US Department of Labor table.

Takeaways

When a rule is an election, model the election as an input and the "no election" case as a default, separately.
Test for "not provided" with == null or an explicit check. Never use || on a number that can legitimately be zero.
Write the expected values by hand first, then compare with the engine.
Say what the number is not. A withholding estimate is not a tax bill.
If a primary source is blocked, find a copy of the same document on another host and say that you did.

This post was drafted by an AI assistant that helps run this account. The code and numbers are from the real project and were checked against it.

My duplicate-content check passed the page it should have blocked

Muzammil Hussain — Mon, 02 Nov 2026 04:52:11 +0000

I run a site of free calculators, and I wrote a gate that stops me from building a page that competes with one I already have. On its first real day it was wrong twice, once in each direction. Here is the code, the two failures, the fix and the test table.

What the gate is for

Before a new page gets built, the research script compares its target keyword with every page on the site. If an existing page already covers the topic, the run fails and I either extend that page or explain, in one line, why the intent differs. Two pages chasing one query split their rankings and neither does well. I found that out the slow way: Search Console showed 63 queries (4 or more impressions each) in 28 days where two of my own URLs appeared.

Version 1 was the obvious thing. Lowercase, drop stopwords and the word "calculator", then compare word sets.

const toks = (t) => new Set(String(t).toLowerCase().replace(/[^a-z0-9 ]+/g, ' ')
  .split(/\s+/).map((w) => w.replace(/s$/, '')).filter((w) => w && !SW.has(w)));
const jac = (a, b) => { let i = 0; for (const x of a) if (b.has(x)) i++; return i / (a.size + b.size - i); };
const subset = (a, b) => a.size > 0 && [...a].every((x) => b.has(x));
// strong overlap: jac >= 0.67, or one set contains the other and jac >= 0.5

Each keyword was compared with each page's primary keyword, title and slug.

Failure A: it blocked a page that does not exist

The first keyword I ran was "quebec paycheck calculator". The gate failed it: strong overlap with /paycheck-calculators/ and /take-home-pay-calculator/. I have no Quebec page. Both existing pages are generic, so their word sets are subsets of the keyword's, and "subset in either direction" counted that as a match. The extra word, a place, is exactly what makes the query different.

The fix is to allow the subset test in one direction only. An existing page covers a keyword only when the page already contains every word of the keyword:

const covered = pageSets.some((x) => subset(kt, x) && jac(kt, x) >= 0.5);

A generic page no longer blocks a specific keyword. A page that says everything the keyword says still does.

Failure B: it passed a page I had already written

I then planned a "BC income tax calculator" (6,600 searches a month in Semrush's Canada data). The gate said no strong overlap. It was wrong. The day before, I had published a BC paycheck calculator, and it already carried the phrase: in an FAQ question, in bold in a section about what people call the tool, and again as "income tax calculator BC". Its meta description said "income tax calculator" too. Four windows of text in total.

The gate looked at titles and slugs. The page titled "BC Paycheck Calculator" shares only the word "BC" with "bc income tax calculator", so the sets looked different. The page text said otherwise.

So the gate now also reads the built pages. For each keyword it looks for a window, a few words longer than the keyword, in which all the keyword's words appear in any order (this version keeps the word "calculator", because here it matters). Two or more windows on one page counts as the page already targeting that phrase:

const need = [...toksKeep(kw)];
let hits = 0, i = 0;
while (i < words.length) {
  const win = words.slice(i, i + need.length + 3);
  if (need.every((n) => win.includes(n))) { hits++; i += need.length + 3; } else i++;
}
if (hits >= 2) textHits.push({ keyword: kw, page, occurrences: hits });

Run against the real pages, it flags the BC page (4 windows) and the Alberta one (3 windows). I dropped both planned pages and retitled the existing ones so the title leads with "income tax calculator", the phrase people actually search.

One bug nearly slipped through even then. I removed a trailing "s" from keyword words but not from page words, so "vs" became "v" on one side only and "RRSP vs TFSA" never matched. Normalise both sides the same way.

The test table

Keyword	Existing page text	Should block?	Result
quebec paycheck calculator	paycheck calculators	no	no
quebec take home pay calculator	take home pay calculator	no	no
illinois paycheck calculator	illinois paycheck calculator	yes	yes
time and a half calculator	time and a half calculator	yes	yes
credit card minimum payment	credit card minimum payment calculator	yes	yes
rrsp vs tfsa	tfsa limit 2026	no	no
rrsp tax refund calculator	rrsp deduction limit calculator	no	no
ontario minimum wage	ontario paycheck calculator	no	no
ontario paycheck calculator	ontario paycheck calculator 2026	yes	yes
overtime pay calculator	overtime calculator	yes in practice	no

The last row is the honest one. "Overtime pay calculator" against my overtime page is real cannibalization. The word "pay" is an extra token, so the gate lets it through. Word overlap cannot see near-synonyms.

What it cannot see, and what covers it

For that gap I rely on Search Console. A query with query and page as dimensions, grouped by query, lists every query where two of my URLs show up. I re-run it every Monday and log the count. It was 63 this week, and the list is the to-do for merging or separating pages.

Takeaways

A check that compares titles and slugs only sees the page's label. Read the page text too.
Subset tests need a direction. "The page contains all of the keyword" is a different claim from "the keyword contains all of the page".
Normalise both sides of a comparison the same way.
Keep a table of cases that must pass and cases that must fail, including one you know it will get wrong.
Use the search engine's own data to check the checker.

This post was drafted by an AI assistant that helps run this account. The code and numbers are from the real project and were checked against it.

A build check that stops stale numbers, and the one error it could not catch

Muzammil Hussain — Sun, 18 Oct 2026 13:37:57 +0000

I run a small site of calculators (pay raise, credit card payoff, overtime tax and so on). Each page has the calculator, a formula and worked examples written in prose: "a 3% raise on $60,000 makes $61,800". The usual way those drift apart is that someone changes the code and forgets the text.

So the page text is not written by hand. It is generated from the same module the calculator uses, and every number that goes into a sentence is checked against a value worked out on paper first:

// Build-time only, never shipped to the browser.
export function mustBe(label, actual, expected, eps = 0.005) {
  if (!(Math.abs(actual - expected) < eps)) {
    throw new Error(`BUILD CHECK FAILED: ${label}: calculator gave ${actual}, hand-check says ${expected}`);
  }
}

If the calculator changes behaviour, the page does not build. That is the whole mechanism.

The case where it worked

The pay raise page compares a raise with inflation. It quotes the US consumer price rise from a small block of dated facts:

const FACTS = { checked: '2026-10-11', expires: '2027-04-30', cpi: 3.4, cpiMonth: 'August 2026' };

and the example sentence is backed by a hand-check:

const real = ((1 + nominal / 100) / (1 + FACTS.cpi / 100) - 1) * 100;
mustBe('real change of a 3% raise at 3.4% inflation', real, -0.3868, 0.0005); // 1.03 / 1.034 - 1

On 14 October the Bureau of Labor Statistics published September CPI: 3.7%, up from 3.4%. When I went to update the page on 18 October I changed cpi to 3.7 and ran the build. It stopped:

BUILD CHECK FAILED: real change of a 3% raise at 3.4% inflation:
calculator gave -0.6750241080038522, hand-check says -0.3868

That is the behaviour I wanted. The sentence "a 3% raise buys what $59,767.89 bought before" could not be published with the new inflation figure in it. I recalculated by hand (1.03 / 1.037 − 1 = −0.6750%, and $61,800 / 1.037 = $59,594.99), updated the three expected values, and the build passed.

The case where it did not

The same day I checked every figure on the site against its source, and found a mistake that every test had passed.

Two pages quote the Federal Reserve's average credit card interest rate and call it the figure for "the second quarter of 2026": 22.25% on accounts charged interest, 21.16% across all accounts. The Fed's G.19 release shows those are the second quarter of 2025 values. The second quarter of 2026 figures are 22.15% and 20.94%.

Nothing in the build could have flagged it. The calculator was correct. The text was generated from the calculator, and the hand-checks compared the calculator with itself. The label "second quarter of 2026" was a string I typed. A check that compares code with text has no way to know that a number is attached to the wrong period in the real world.

The visible effect was small. On a $5,000 balance paid at $200 a month, interest at the quoted average rate was $1,779.73 instead of $1,767.76, a difference of $11.97. The wrong label was the real problem: a page that cites a source and cites it wrongly has lost the one thing it claims to offer.

I fixed both pages, and added a public entry to the site's corrections page stating what was wrong.

What the build check does not cover

Writing this down made the boundary plain:

Code versus text: covered. The text is generated from the code and compared with hand-checked values.
Facts versus their source: not covered. A rate, a threshold or a date is only as right as the person who typed it, on the day they typed it.
Facts versus time: only partly covered. FACTS.expires makes the build refuse to publish after a set date, which forces a re-check, but it says nothing about the six months before that.

What I added

A script that reads the source, not the code. It runs every two days and writes a report; it never edits the site.

It fetches the Fed's G.19 page and compares the whole credit card row of the table with the row I last verified. Any new month or quarter changes the row and raises a flag, including when the figure I quote has not changed. That false alarm is deliberate. A silent miss is worse.
It recomputes the CPI 12-month change from the BLS data series and compares it with the page: September 2026 comes out at 3.74%, which BLS rounds to 3.7%.
For sources it cannot parse reliably, it flags the release date as due a few days ahead, and a human checks the source.
It also fetches each live page and confirms that the figure I registered is still there and the stale one is not.

I tested it the only way that means anything: I set the registered CPI to 3.6% and confirmed it reported the mismatch.

Tradeoffs

Whole-row comparison on the Fed page is brittle. If the Fed reformats the table, the script reports "anchor not found" and I look at it by hand. I prefer that to a clever parser that quietly returns the wrong column.

Generating text from code also constrains how the pages can be written. A sentence like "this is usually a bad idea" has no value to assert, so it lives outside the generated part. The checks cover arithmetic and quoted figures, not judgement.

The calculators, the formulas and the corrections log are at sumfern.com/methodology.

Disclosure: this article was written by an AI assistant (Claude) for the editor of Sumfern, who owns the project. The events, figures and code are from the real repository and the official Federal Reserve and BLS releases, and were checked against them before publishing.