Per-Seat vs Usage-Based Pricing Toggle — Free HTML CSS JS Snippet

Plenty of "pricing model toggle" components are cosmetic — they swap a label between "per seat" and "usage-based" while running the exact same multiplication underneath. This snippet builds two genuinely different pricing formulas, each with its own independent input and its own unit economics, and switches between them cleanly without either one leaking into the other.

Two real formulas, not one formula relabeled

Per-seat pricing is seats × SEAT_RATE — a flat \$15 charged for every team member, regardless of how much any individual uses the product. Usage-based pricing is calls × USAGE_RATE — a per-unit charge (\$0.02 per API call) that has nothing to do with headcount at all; a team of two making a million calls pays far more than a team of fifty making a thousand. These are different mental models for the same underlying question ("what am I actually paying for?"), and the snippet keeps them structurally separate: two different input fields, two different rate constants, two different result-formula strings.

Independent, isolated inputs per model

Switching modes doesn't just change which formula runs against a shared number — it swaps to an entirely separate input (#vmtSeats vs. #vmtUsage) with its own stepper buttons, its own min/max bounds, and its own unit label ("seats" vs. "API calls per month, in thousands"). This matters because the two inputs represent genuinely different things; forcing them to share one number field would misrepresent at least one of the two models the moment a visitor tried to enter a value that made sense for the other.

The formula is shown, not just the total

Beneath the headline dollar figure, resultFormula renders the literal arithmetic — "8 seats × $15 = $120/month" or "400,000 calls × $0.02 = $8,000/month" — computed from the exact same input the total was computed from, so the total is always traceable back to a number the visitor themselves typed in.

Clamping keeps the math sane at the edges

Both inputs run through clamp(), bounding seats to 1–500 and usage to 1–10,000 (thousand calls), and both stepper buttons and direct typing funnel through the identical recalc() function — so there's exactly one code path computing the cost for each model, not two that could drift out of sync (one driven by buttons, one by typing).

Why this distinction matters for buyers

A team evaluating vendors genuinely needs to know which pricing model fits their usage pattern — a small team with heavy API usage will pay far less under usage-based pricing than per-seat, and vice versa for a large team with light usage. Letting a prospect toggle between both models with their own real numbers, live, turns an abstract pricing-page comparison into a concrete answer to "which one is cheaper for us."

Customizing it

Change SEAT_RATE and USAGE_RATE to your real pricing, adjust the input bounds, or add a third pricing model (e.g. flat-tier) as a third switch option following the same isolated-panel pattern. Pair it with pricing toggle for a monthly/annual dimension layered on top, or seat-based pricing calculator for a per-seat-only deep dive.