Annual salary per hour
A salary of 52,000 for 40-hour weeks over 52 weeks is worth 25 an hour, because those weeks add up to 2,080 working hours. Enter your real hours, not the contract's, to see what a job truly pays. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Annual salary
- 52,000
- Hours per week
- 40
- Weeks per year
- 52
- Hourly rate
- 25
The annual salary per hour calculator answers one precise question: what is my yearly pay actually worth for each hour I work?
Why an hourly view of a salary matters
Job offers, freelance quotes and overtime decisions are all easier to compare when they share one unit, and the hour is usually the most honest one. A salary of 60,000 a year sounds larger than a 30-per-hour contract until you account for the weeks actually worked; a salaried role that quietly expects 50-hour weeks pays less per hour than one that respects 40.
The annual salary per hour conversion makes those comparisons mechanical: divide the yearly pay by the total hours worked in the year, which is simply hours per week multiplied by weeks per year.
How the calculation works
The formula is a single closed-form division: hourly rate equals the annual salary divided by the product of hours per week and weeks per year. The three inputs are coerced to finite numbers; numeric strings are accepted so form data can be sent as-is. The salary may be zero — someone on unpaid leave genuinely earns zero per hour — but it may not be negative.
The result is rounded to six decimal places, which keeps outputs byte-identical across machines and safe to compare in tests, caches and audit logs. There is no hidden rounding mode, no locale-dependent parsing of thousands separators, and no approximation step: what you send is what is divided, and the echo of the normalized inputs in the response lets a caller confirm exactly which numbers entered the formula before trusting the rate.
Choosing hours and weeks honestly
The quality of the result depends entirely on how truthful the two schedule inputs are. The classic full-time baseline is 40 hours per week and 52 weeks per year, giving 2,080 working hours, but real calendars differ: two weeks of unpaid vacation means 50 weeks, a contract with public holidays unpaid might mean fewer, and part-time arrangements change the hours side. Salaried staff who regularly work late should use their real average, not the contractual figure, or the hourly rate will flatter the job.
When in doubt, model the pessimistic case: use the longer hours and the shorter week count, and treat any rate that still looks good as a genuinely good one.
What you can do with it
Compare a salaried offer with contract work
Convert the salaried offer to an hourly rate and compare it directly with a freelancer quote, adjusting weeks per year for unpaid leave.
Price overtime and extra projects
Derive the true hourly value of a salary to decide whether an extra project or weekend shift is worth the effective pay.
Build a payroll sanity check
Verify in an automated pipeline that a payroll run's implied hourly rate matches the contracted salary, failing loudly on bad schedule data.
FAQ
What is the formula?
A 52,000 salary at 40 hours and 52 weeks gives exactly 25 per hour.
Why was my input rejected?
Hours per week and weeks per year must be greater than zero, the salary cannot be negative, and every value must be a finite number. The error message names the field at fault.
Can I use 50 weeks instead of 52?
Yes — use the weeks you are actually paid or work in a year. 50 weeks models two weeks of unpaid leave and raises the effective hourly rate.
Does it handle taxes or net pay?
No. It converts the gross figure you provide. Convert your net salary separately if you want a take-home hourly rate.
Is my salary data stored?
No. The numbers are processed in memory and discarded; only the hourly rate is returned.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/fin/annual-salary-per-hour \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"annual_salary":52000,"hours_per_week":40,"weeks_per_year":52}'const res = await fetch("https://api.kit.forhosting.com/fin/annual-salary-per-hour", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"annual_salary": 52000,
"hours_per_week": 40,
"weeks_per_year": 52
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/fin/annual-salary-per-hour",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"annual_salary": 52000,
"hours_per_week": 40,
"weeks_per_year": 52
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/fin/annual-salary-per-hour", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"annual_salary":52000,"hours_per_week":40,"weeks_per_year":52}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"annual_salary":52000,"hours_per_week":40,"weeks_per_year":52}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/fin/annual-salary-per-hour", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"annual_salary": 52000,
"hours_per_week": 40,
"weeks_per_year": 52
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "fin.annual_salary_per_hour",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
You provide the annual salary, the average hours you work per week, and the number of weeks you count in a year, and the API returns a single hourly rate. It is the same arithmetic an HR spreadsheet does, exposed as a deterministic one-call endpoint with strict input validation, so automated pipelines get a number or a clear rejection — never a silent wrong answer.
Why an hourly view of a salary matters
Because the endpoint is deterministic and free of rounding surprises, the number you get in the browser is exactly the number your code gets from the API, so you can prototype by hand and automate later without re-checking the math. Recruiters, union negotiators and payroll auditors all lean on this same conversion when they benchmark compensation across roles that quote pay in different units, which is why getting it from a validated, reproducible endpoint beats a row of ad-hoc spreadsheet cells that nobody re-verifies.
How the calculation works
Hours per week and weeks per year must both be strictly greater than zero, because a zero there would mean either division by zero or a schedule that describes no work at all; both cases are rejected with an invalid_input error that names the offending field, and invalid requests are never billed.
Choosing hours and weeks honestly
For freelancers comparing a day rate against a salary, run the salary through this endpoint and compare the hourly figures directly. The capability runs on our global edge with nothing stored, and the same code runs free on this page, so you pay $0.002 per request only when you automate it.
Technical questions
What does it cost?
$0.002 per request. It is also free to run in your browser on this page — the same code executes in both places.