Salary Calculator

New to the mechanics? The companion guide Salary conversions and overtime pay builds every conversion from the ground up on fictional figures and sets the converter beside the overtime engine, and it sits in the full guides library next to the methodology page.

How the conversion works

The converter never jumps straight from one period to another. It first annualizes the amount you enter, then divides that one annual total back into each period. With a 40-hour, 5-day week, 25 per hour means 25 × 40 × 52 = 52,000 per year — which is 4,333.33 monthly, 2,000 bi-weekly, and 2,166.67 semi-monthly. Routing everything through the annual figure is what keeps the periods mutually consistent: feed any one of the outputs back into the tool and you land on the same annual total you started from. Every figure on this page is computed at build time by the same tested engine that powers the form above, so the worked numbers cannot drift from what the calculator returns.

Why each period divides the year differently

The annual total is split by a fixed count of periods per year: 52 weeks, 26 bi-weekly periods, 24 semi-monthly periods, 12 months, 4 quarters, and 1 year. Hourly and daily pay are the two exceptions — they depend on the schedule, because their yearly count is hours-per-week × 52 and days-per-week × 52. Take a fictional 60,000 annual salary on a 40-hour, 5-day week; the converter resolves it to every period at once:

• Hourly — 28.85
• Daily — 230.77
• Weekly — 1,153.85
• Bi-weekly — 2,307.69
• Semi-monthly — 2,500
• Monthly — 5,000
• Quarterly — 15,000
• Annual — 60,000

Read the list and the common conversion errors become visible. A month is not four weeks: with 52 weeks and 12 months, each month averages about 4.33 weeks, so the monthly 5,000 is noticeably more than four times the weekly 1,153.85. Bi-weekly and semi-monthly are the pair most often confused, because they sound interchangeable and are not. The same 60,000 splits into a smaller bi-weekly 2,307.69 across 26 periods and a larger semi-monthly 2,500 across 24 — the bi-weekly schedule making up the difference with two extra cheques a year. Neither is more money over the year; they cut the same annual total into a different number of pieces.

The schedule is part of the number

Hours and days per week are not decoration. For an hourly rate they set the whole annual total, which is why a quoted "annual equivalent" for anything short of full time can mislead. The same 25 per hour worked on a 20-hour week annualizes to 26,000, exactly half the full-time 52,000, and the monthly figure falls from 4,333.33 to 2,166.67. The hourly rate has not moved at all; the yearly figure has halved because half as many hours feed it. Whenever an annual number is set against an hourly one, the schedule behind each has to match, or the comparison is between two different working years.

Reading an annual salary back to an hourly rate

Because the annual pivot is symmetric, the converter runs just as well in reverse. Enter 60,000 as an annual salary on a 40-hour, 5-day week and it resolves to 28.85 per hour, 230.77 per day, and 1,153.85 per week. That is the move that makes a headline salary comparable to an hourly rate: convert both to the same period before judging them. It also exposes a gap no annual figure shows on its own — the hours behind it.

It does not matter which period you enter

One consequence of the annual pivot is easy to miss: on a fixed schedule, the period you choose in the "Per" field changes nothing about the output. Entering 60,000 a year, 5,000 a month, or 28.85 an hour on the same 40-hour, 5-day week all produce the identical table, because each of those amounts annualizes back to the same 60,000 before the converter divides it out again. The "Per" field only tells the tool which period your input number already belongs to; it does not give that period any special weight in the result. So enter whichever figure you actually know — a quoted annual salary, a monthly draw, a posted hourly rate — and read the rest off the same consistent set, rather than trying to pick a "canonical" period to start from.

Comparing job offers fairly

Convert both offers to the same period before comparing — annual for the big picture, hourly for what your time actually earns. Take two fictional offers: Offer A at 65,000 a year on a 40-hour week, and Offer B at 68,000 a year on a 45-hour week. Offer B's larger annual total looks like the better deal, yet the extra hours feed more time into the same year: Offer A works out to 31.25 an hour while Offer B is only 29.06 — a lower rate for your time despite the bigger headline. The weekly figures tell the same story from the other side, 1,250 against 1,307.69. Remember also that this page compares gross pay only: benefits, retirement matching, bonuses, and tax treatment can move the real value of an offer substantially, and none of them are in these numbers.

Every figure here is gross

The pay engine returns gross, pre-tax amounts, and says so rather than pretending otherwise. Withholding, payroll taxes, pension contributions, and benefit deductions depend on jurisdiction and personal election, and cannot be inferred from a rate and a schedule — so the take-home figure on an actual pay cheque will be lower than anything shown here, by an amount only a jurisdiction-aware tool can work out. This is the same boundary the methodology draws around every Sumvia calculator: the tools implement general arithmetic, while specific domains such as tax rules impose their own conventions a generic tool does not know. The converter also assumes a full 52-week year with no unpaid leave; if you expect unpaid time off, multiply the hourly rate by the hours you will truly work rather than trusting the annualized figure, which counts every week as worked.

What the converter checks before it answers

The conversion only runs on inputs the engine accepts, and the bounds are deliberately wide but finite. A pay amount has to be zero or positive and no larger than a generous upper limit the engine enforces — the same discipline of a documented, finite input range the methodology page describes for every Sumvia tool, so a value beyond the limit is reported as out of range rather than quietly computed; hours per week must sit between zero and the 168 a week actually contains; days per week between zero and 7. Anything outside those limits returns an explicit, readable message instead of a confident wrong number — a schedule of nine days a week has no meaning, so the tool says so rather than inventing one. This is the division of labour the methodology describes: the validation and the arithmetic live in a small, tested function, and the interface only formats and displays what that function returns, never doing sums of its own. The same discipline is why the examples in this prose cannot drift — they are computed at build time by that very function, and a disagreement between the copy and the code would stop the page from building at all.

When a conversion lands on a repeating decimal

Dividing an annual total into periods often produces a figure that does not terminate. Converting a fictional 2,500/month salary to weekly gives 576.923077 — the engine holds that value at full internal precision and the screen shows 576.92 once rounded to two places for money. Two calculators can therefore display slightly different final digits for the same salary and both be right: the difference is in display rounding, not in the arithmetic. The methodology page documents the full rounding policy the engine and formatter apply. The practical consequence is the usual one for chained work: if you copy a converted figure and feed it into further hand calculations, you are working from the displayed, rounded number, so prefer doing the whole conversion in one pass.

Frequently asked questions

Values are processed locally in your browser and never transmitted. This tool is for general information, not financial advice — verify consequential figures with your employer or a qualified professional. See the methodology page.