Year progress percentage
July 1, 2024 marks exactly 50% of the year: day 183 of 366, with 183 days still to go. Enter any date to feed a progress bar, an annual goal tracker or a seasonal plan with the same figure. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Date
- 2024-07-01
- Year
- 2,024
- Month
- 7
- Day
- 1
- Day of year
- 183
Year progress is the share of a calendar year that has already passed by a given civil date, expressed as a percentage from just above zero on the first of January through one hundred on the thirty-first of December. Product dashboards, annual goal trackers, seasonal marketing calendars, and personal productivity tools all need that number without fighting host time zones or daylight-saving tables. This calculator accepts a single ISO calendar date in the strict form year-month-day with four digits, two digits, and two digits, checks that the day really exists on the Gregorian calendar including leap-year Februaries, computes the day-of-year ordinal, and returns percent equal to one hundred times that ordinal divided by three hundred sixty-five or three hundred sixty-six. The response also includes remaining days, remaining percent, a leap flag, and the year length so progress bars and countdowns stay consistent. Impossible dates such as the twenty-ninth of February in a common year or the thirty-first of April fail with a clear validation error instead of a silent wrap.
How year progress percentage is computed from an ISO date
Start with a calendar date written as year, month, and day in the international ISO form with hyphens and fixed widths so that every client agrees on the same three integers. First confirm that the year lies in a practical Gregorian range and that the month is between one and twelve. Next apply the leap-year rule used by civil calendars worldwide: a year is a leap year when it is divisible by four, except that century years are leap years only when they are also divisible by four hundred.
That rule makes February twenty-nine legal in years such as two thousand twenty-four and two thousand, and illegal in two thousand twenty-three and nineteen hundred. With leap status known, look up the length of each month for that year and reject any day that exceeds the month length, for example the thirty-first of April or the thirtieth of February. When the triple is valid, sum the lengths of every complete month before the given month and then add the day-of-month to obtain the day-of-year ordinal.
January first is always one, March first is sixty-one in a leap year and sixty in a common year, and December thirty-first is three hundred sixty-six or three hundred sixty-five. Year progress percent is defined as one hundred multiplied by day-of-year divided by the year length, so the last day of the year is exactly one hundred percent and earlier days scale linearly. Remaining days equal year length minus day-of-year, and remaining percent is the complementary fraction times one hundred.
Where year progress percentage calculators show up in real work
Product and growth teams draw annual progress bars for OKRs, revenue targets, and content calendars and need a single trusted percent that matches civil dates rather than Unix epoch fractions that ignore leap days. HR and finance ops track leave policies, fiscal reporting windows, and training deadlines as a share of the year so dashboards stay readable for non-engineers. Marketing schedules seasonal campaigns by asking what percent of the year has already passed when a launch date is fixed.
Software that must stay free of time-zone libraries still needs a pure calendar percent for maintenance windows, compliance calendars, and personal productivity widgets defined by civil dates. If you later need only the day-of-year ordinal without a percent, business-day counts between two dates, age from a birth date, full Julian day numbers, or week-of-year numbering under ISO eight thousand six hundred one, treat those as separate search intents and landings rather than overloading this year-progress-percentage page.
What you can do with it
Annual OKR and goal dashboards
Convert any ISO date to percent of year elapsed so progress bars and remaining-percent labels stay leap-aware without host time zones.
Seasonal marketing calendars
Map campaign launch dates to year-progress percentages for planning decks and automated seasonal triggers.
FAQ
Does a leap year change the percentage?
Yes. Leap years have 366 days, so the same month-day after February maps to a different percent than in a common year. February 29 is accepted only in leap years.
What happens if the date is invalid?
Wrong shape, out-of-range month, or impossible days such as 2023-02-29 are rejected and not charged.
Is this the same as day of the year?
No. Day of the year returns the ordinal 1–366. This capability returns the elapsed percentage of the year (and remaining percent), which is a different search intent even though both use calendar math.
What does it cost?
The browser tool is free and runs locally.
How is the year progress percentage calculated?
The day's position in the year is divided by the number of days in that year, 365 or 366, and multiplied by 100. That is why December 31 always comes out at exactly 100%.
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/date/year-progress \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"date":"2024-07-01"}'const res = await fetch("https://api.kit.forhosting.com/date/year-progress", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"date": "2024-07-01"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/date/year-progress",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"date": "2024-07-01"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/date/year-progress", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"date":"2024-07-01"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"date":"2024-07-01"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/date/year-progress", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"date": "2024-07-01"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "date.year_progress",
"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
What you send and what you get back
Send one required string field named date containing a strict ISO calendar day such as two thousand twenty-four hyphen zero seven hyphen zero one. Days that match the pattern but are not real calendar dates, including non-leap February twenty-nine and month values outside one through twelve, also fail with a message that names the problem so clients can correct the input without guessing. Classic checks include January first mapping to roughly zero point two seven percent in a common year, July first near the mid-year mark with a one-day leap shift between leap and common years, and December thirty-first mapping to exactly one hundred percent. Missing fields, non-string values, and strings that do not match the four-two-two digit pattern fail with invalid_input and are not charged. On success the response echoes the normalized date string, the numeric year, month, and day components, the day_of_year integer from one through three hundred sixty-five or three hundred sixty-six, a boolean is_leap_year flag, days_in_year as three hundred sixty-five or three hundred sixty-six, remaining_days until the last day of that year, percent as the elapsed year fraction times one hundred, remaining_percent as the complementary fraction times one hundred, and a short formula string that documents the leap rule and the percent definition. Pricing for successful API calls is the published base of $0.002 per item; validation failures do not consume prepaid balance.
Where year progress percentage calculators show up in real work
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
Compliance and leave trackers
Stamp annual policies with a stable percent and remaining_days from strict YYYY-MM-DD inputs, with clear invalid_input on bad dates.
Technical questions
How is year progress percentage calculated?
percent = 100 × day_of_year / days_in_year, where day_of_year is the 1-based ordinal of the ISO date and days_in_year is 365 or 366 under Gregorian leap rules. December 31 is always exactly 100%.