Waist-to-height ratio calculator
An 80 cm waist with a height of 170 cm gives a ratio of 0.47, inside the healthy band below 0.5. Enter both measurements in the same unit and see your band at once. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Waist
- 80
- Height
- 170
- Ratio
- 0.4705882353 ratio
- Waist to height ratio
- 0.4705882353
- Risk category
- healthy
- Risk level
- healthy
Waist-to-height ratio, often abbreviated WHtR, is a simple central-adiposity index formed by dividing waist circumference by standing height when both lengths use the same unit. Public-health guidance popularized the rule of thumb that waist should stay under half of height, which corresponds to a ratio below zero point five, because abdominal fat tracks cardiometabolic risk better than weight alone in many screening contexts. This calculator applies that pure division exactly, labels the result with four Ashwell-style bands underweight, healthy, increased, and high, and rejects zero or negative height so a undefined ratio never reaches clients as Infinity.
How waist-to-height ratio is computed and labeled
Start from two positive linear measurements taken with the same unit system: waist circumference, usually measured at the midpoint between the lowest rib and the iliac crest or at the narrowest waist depending on protocol, and standing height without shoes. The waist-to-height ratio is simply waist divided by height. Because both lengths cancel, the ratio is dimensionless and comparable across people of different stature in a way that raw waist alone is not.
This capability implements the analytic path only: no machine learning, no lookup tables fetched at runtime, and no random jitter. Height must be strictly greater than zero; a zero height would make the quotient undefined, and a negative height is non-physical, so both cases fail early with invalid input rather than returning Infinity or an absolute value. Waist must also be positive so a non-physical circumference cannot produce a misleading category.
Risk labels follow a common four-band Ashwell-style chart used in educational and consumer health tools: ratios strictly below zero point four map to underweight or low, ratios from zero point four inclusive up to but not including zero point five map to healthy, ratios from zero point five inclusive up to but not including zero point six map to increased, and ratios at or above zero point six map to high. The widely cited keep-waist-under-half-your-height message corresponds to staying in the healthy band below zero point five.
These labels are screening-style categories for education and product demos, not a clinical diagnosis; real care decisions need qualified professionals and fuller context this tool does not collect.
Where waist-to-height ratio calculators show up in real work
Fitness coaches and digital health apps still teach the keep waist under half your height message as a transparent central-adiposity screen before introducing waist-hip ratio, body mass index, or body-composition scans, so a single oracle that returns the exact quotient and band speeds onboarding copy and demo setup. Research assistants preparing synthetic screening datasets need deterministic WHtR labels from waist and height without network calls or model drift.
Public-health workshops and corporate wellness portals often walk through sample adults with tape-measure examples, and clear rejection of zero height prevents broken demos. If you later need body mass index, waist-hip ratio, basal metabolic rate, or body-fat equations, treat those as separate search intents and landings rather than overloading this waist-to-height ratio calculator page. Always frame results as educational estimates, not medical diagnosis; clinical decisions require qualified professionals and context this tool does not collect.
What you can do with it
Coaching and wellness intake
Compute a transparent WHtR and Ashwell-style risk band from tape-measure waist and height before deeper body-composition work.
Classroom and public-health demos
Generate deterministic waist-to-height ratios for lesson sets so teachers and auto-graders share one ground truth including zero-height rejection.
FAQ
What is waist-to-height ratio?
WHtR is waist circumference divided by standing height using the same linear units. It is a simple central-adiposity index; many guides recommend keeping the ratio below 0.5 (waist less than half of height).
What happens if height is zero or negative?
Height must be strictly greater than zero because a zero height makes the ratio undefined and a negative height is non-physical.
How are risk categories assigned?
Ashwell-style bands: underweight below 0.40, healthy from 0.40 up to below 0.50, increased from 0.50 up to below 0.60, and high at or above 0.60. Labels are educational screening categories, not a clinical diagnosis.
Do waist and height need the same units?
Yes. Both must use the same linear unit (for example both cm or both inches). The ratio is unitless, but mixed units would produce a meaningless number.
What does it cost?
The browser tool is free and runs locally.
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/health/waist-height-ratio \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"waist":80,"height":170}'const res = await fetch("https://api.kit.forhosting.com/health/waist-height-ratio", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"waist": 80,
"height": 170
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/health/waist-height-ratio",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"waist": 80,
"height": 170
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/health/waist-height-ratio", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"waist":80,"height":170}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"waist":80,"height":170}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/health/waist-height-ratio", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"waist": 80,
"height": 170
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "health.waist_height_ratio",
"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
How waist-to-height ratio is computed and labeled
Identical waist and height always yield the same JSON.
What you send and what you get back
Send two fields. Both fields are required. When height is zero or negative the error message states that height is zero or negative so the waist-to-height ratio is undefined or non-physical, matching the product contract that division by zero never masquerades as a result. Classic smoke checks include an eighty centimeter waist with one hundred seventy centimeter height for a healthy-band ratio near zero point four seven, and a one hundred five centimeter waist with the same height for an increased-band ratio near zero point six two when high, or adjust waist to ninety five for increased near zero point five six. Convert inches to centimeters or keep both measurements in inches before calling if your forms collect imperial units, because the ratio itself is unitless but the two inputs must match. Waist is circumference in the same linear unit as height, typically centimeters, and must be a finite number strictly greater than zero; aliases waist_cm, waist_circumference, and circumference are accepted. Height is standing height in that same unit and must also be finite and strictly greater than zero; aliases height_cm and cm are accepted. Missing fields, non-numeric strings, NaN, Infinity, zero, and negative values fail with invalid_input and are not charged. On success the response returns ratio and waist_to_height_ratio as the same cleaned quotient, the cleaned waist and height echoes, unit ratio, risk_category and risk_level strings, a human threshold_note, the formula string WHtR equals waist over height, method waist_to_height_ratio, and a thresholds object summarizing the four bands. Pricing for successful API calls is the published base of $0.002 per item; validation failures do not consume prepaid balance.
Where waist-to-height ratio calculators show up in real work
Secondary-school and college health classes assign WHtR drills alongside BMI so students see why height-normalized waist can flag risk when BMI looks normal; matching hand arithmetic to API output matters more than asymptotic cost. Because this capability is a pure parse engine, API pricing is the published base of $0.002 per successful item and failed validation does not consume balance.
Integration use cases
App and API fixtures
Bulk-produce golden WHtR JSON for onboarding flows and regression tests without network calls or non-deterministic models.