Intermittent fasting window calculator
Turns your first meal and a fasting ratio into clock times: start eating at 12:00 on a 16:8 schedule and your window runs 12:00–20:00, with the fast lasting from 20:00 until 12:00 the next day. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- First meal
- 12:00
- Fasting ratio
- 16:8
- Fasting hours
- 16
- Eating hours
- 8
- Eating start
- 12:00
- Eating end
- 20:00
Intermittent fasting schedules are defined by how many hours you fast versus how many hours you allow food each day. This intermittent fasting window calculator takes the clock time of your first meal and a daily fasting ratio such as sixteen to eight, eighteen to six, or fourteen to ten, then returns the exact eating window start and end, the complementary fasting window, and a short formula string you can show beside the result. The arithmetic is pure minute-of-day modular math on a twenty-four-hour cycle: no wall clock, no timezone database, and no random seed. Use it for personal IF planners, wellness product demos, coaching portals, and automation that needs a transparent eating-window baseline without shipping a full nutrition library.
What the intermittent fasting window model computes from first meal and ratio
Daily intermittent fasting protocols partition a twenty-four-hour day into a fasting block of F hours and an eating block of E hours, written as the ratio F colon E. Classic examples include sixteen eight, eighteen six, twenty four, fourteen ten, and twelve twelve. Both windows are returned as zero-padded HH:MM strings and as compact range labels such as twelve zero zero en dash twenty zero zero so a UI can paint a day timeline without further parsing.
People who are pregnant, underage, recovering from disordered eating, or under clinical care should not treat a free window calculator as medical advice. Treat the output as the transparent arithmetic schedule it is meant to be: given a first meal and a published ratio, here is when the eating window opens and closes and when the fast runs until the next first meal.
Who uses eating-window schedules, and where
Wellness apps and coaching portals often need a transparent first-pass eating schedule the moment a user picks a protocol and a preferred lunch or dinner start, before any food diary or continuous glucose data is available. Embedding this calculator gives a published formula, fixed daily partition, and HH:MM outputs that product copy and support teams can quote without reverse-engineering a black-box scheduling library. Habit trackers can recompute windows when a user shifts first meal earlier for summer light or later for social dinners, always with the same pure function.
Prefer clinical guidance when medical decisions depend on fasting, and treat this output as the conventional clock-window estimate it is meant to be: simple, explainable, and deterministic.
What you can do with it
Personal IF planners and habit apps
Show eating and fasting clock bounds from a chosen first meal and protocol such as 16:8 or 18:6 with HH:MM strings a UI can highlight on a day timeline.
Wellness education and content widgets
Demonstrate common intermittent fasting ratios with a deterministic oracle that rejects non-positive hours and ratios that do not sum to twenty-four.
Coaching and batch schedule rebuilds
Recompute daily eating windows for client protocols from stored first-meal and ratio columns without timezone-sensitive Date libraries.
FAQ
Why must fasting plus eating equal 24 hours?
This tool models a single daily intermittent-fasting cycle. Multi-day protocols are out of scope.
Is this medical advice about whether I should fast?
No. It only computes clock boundaries for a chosen ratio. It does not assess safety, calories, or clinical suitability. Seek professional guidance when medical decisions depend on fasting.
When does my eating window close if I start at 12:00 on 16:8?
It closes at 20:00, eight hours after your first meal. The fast then runs from 20:00 until 12:00 the next day, when your next first meal opens the window again.
What happens if my eating window runs past midnight?
The times simply wrap around the 24-hour day. With a first meal at 16:00 on a 16:8 schedule, the window ends at 00:00 and the fast lasts until 16:00 the following day.
Which fasting ratios can I use?
Any split of the day into whole hours of fasting and eating, as long as both parts are positive and add up to 24. Common choices are 16:8, 18:6, 14:10, 12:12 and 20:4.
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/if-eating-window \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"first_meal":"12:00","fasting_ratio":"16:8"}'const res = await fetch("https://api.kit.forhosting.com/health/if-eating-window", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"first_meal": "12:00",
"fasting_ratio": "16:8"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/health/if-eating-window",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"first_meal": "12:00",
"fasting_ratio": "16:8"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/health/if-eating-window", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"first_meal":"12:00","fasting_ratio":"16:8"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"first_meal":"12:00","fasting_ratio":"16:8"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/health/if-eating-window", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"first_meal": "12:00",
"fasting_ratio": "16:8"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "health.if_eating_window",
"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
Missing fields, malformed times, non-positive ratio parts, and ratios that do not sum to twenty-four fail with invalid_input instead of inventing a schedule.
What the intermittent fasting window model computes from first meal and ratio
This calculator anchors the eating block to the time you intend to take the first meal: eating_start equals that first_meal clock time, eating_end equals first_meal plus E whole hours modulo twenty-four hours, fasting_start equals eating_end, and fasting_end equals fasting_start plus F whole hours, which lands back on first_meal for any valid daily ratio. The ratio is normalized to integers without spaces so sixteen colon eight and sixteen colon eight with spaces collapse to the same fasting_ratio field.
Input contract, validation, response shape, and deterministic errors
Spaces around the colon are trimmed. Ratios such as sixteen to seven that do not sum to twenty-four are rejected rather than silently stretched, because a daily IF cycle without a full day partition would leave ambiguous leftover hours. POST a JSON object with two required string fields. first_meal is a twenty-four-hour clock time matching optional leading zero on the hour, a colon, and two digit minutes from zero zero through five nine; examples twelve zero zero, eight thirty, and zero zero zero zero are accepted, while twenty-four zero zero, twelve sixty, and bare twelve are rejected. Aliases meal_time, eating_start, and first_meal_time map to the same parse path so forms can keep their preferred names. fasting_ratio is the string F colon E where F and E are positive whole-hour integers that sum to exactly twenty-four; aliases ratio, protocol, and if_ratio are accepted. Zero, negative, fractional, or non-numeric parts fail with invalid_input naming the field and the expected shape. Missing first_meal or fasting_ratio, null bodies, and non-object inputs also fail and are not billed. On success the body always includes first_meal, fasting_ratio, fasting_hours, eating_hours, eating_start, eating_end, fasting_start, fasting_end, eating_window, fasting_window, and a formula string restating the modular offsets. Example: first_meal twelve zero zero with fasting_ratio sixteen colon eight yields an eight-hour eating window from twelve zero zero to twenty zero zero and a sixteen-hour fast from twenty zero zero back to twelve zero zero.
Technical questions
How is the eating window calculated?
eating_start is first_meal. eating_end is first_meal plus the eating hours from the F:E ratio, modulo 24 hours. fasting_start equals eating_end; fasting_end equals fasting_start plus the fasting hours, landing back on first_meal.
Which input fields are required?
first_meal (HH:MM, 24-hour) and fasting_ratio (F:E with positive integers summing to 24). Aliases meal_time, eating_start, first_meal_time, ratio, protocol, and if_ratio are accepted. Invalid input returns invalid_input and is not billed.
What does the intermittent fasting window calculator cost?
The browser widget is free. API calls use prepaid KIT balance at $0.002 per successful task; invalid input is not charged.