Overtime pay calculator

Inputs: hourly rate, regular hours, overtime hours, and multiplier

Negative hour counts and negative multipliers are also rejected so accidental sign flips fail loudly instead of inventing absurd negatives on a payslip. All validation happens before any money math, so bad requests never produce half-filled pay rows. You already decide which hours are regular versus overtime under your local rules; this calculator multiplies what you send rather than inventing a forty-hour week policy. Send a JSON body with four required fields. Hourly rate is the base wage per hour as a non-negative finite number or numeric string; aliases rate, wage, hourly, and pay_rate are accepted when your client already names the field differently. Regular hours are the straight-time hours paid at that base rate; aliases hours, straight_hours, regular, and straight_time map to the same value so form builders can keep familiar labels. Overtime hours are the premium hours for the same pay period; aliases ot_hours, overtime, and ot are supported. Overtime multiplier is the premium expressed as a multiple of the base rate—for example one point five means time-and-a-half and two means double time—not a percentage of the wage; aliases multiplier, ot_multiplier, ot_rate, and premium map to the same field. Negative hourly rates fail validation with invalid_input because they do not describe a normal paycheck. Extremely large rates, hour totals, or multipliers are capped so Worker isolate math stays bounded. Missing any of the four fields fails with invalid_input naming the missing key.

How regular pay, overtime pay, and gross pay are computed

The response also returns ot_hourly_rate as hourly rate times the multiplier so UIs can show the effective overtime wage next to the base rate. The response echoes the normalized hourly rate, regular hours, overtime hours, and overtime multiplier, then returns ot_hourly_rate, regular_pay, overtime_pay, and gross_pay, plus currency_decimals equal to two and method equal to overtime_gross for stable client branching. Use regular_pay alone when you only need the straight-time line; use overtime_pay when a report needs the premium line; use gross_pay when a contractor invoice or weekly estimate needs the combined amount. Identical inputs always produce identical JSON because the path is pure arithmetic with no network, no random seed, and no wall clock.

API usage, pricing, workflows, and practical limits

Call the free in-browser overtime pay calculator for weekly estimates, side-gig invoices, classroom payroll exercises, and quick manager checks without installing another app. Keep rates and hours within ordinary commercial ranges; extreme values are rejected so isolate math stays bounded. The product promise is gross pay from a base rate, a regular and overtime hour split you already chose, and an explicit multiplier—not automatic legal classification of overtime, multi-rate shift differentials, or local statutory OT tables. Those belong in specialized tools with different SEO intent. Use the prepaid API when an HR bot, freelancing dashboard, staffing portal, or timesheet helper needs a stable KIT contract at $0.002 per successful item; validation failures never consume balance after the engine rejects the request. Pair this endpoint with tax or deduction tools only if you already know net-pay rules separately—this capability does not withhold taxes, apply benefits, or convert currencies. Authors shipping SDKs can map regular_pay, overtime_pay, and gross_pay directly into payslip UIs and estimate messages. When you cite the API price in product copy, use the catalog placeholder $0.002 so published pages stay aligned with the live price floor.