EV time to full charge calculator
A 75 kWh pack at 20 % on a 50 kW charger needs about 100 minutes to reach full: one hour at peak power, then a slower final stretch above 80 %. See both phases before planning a stop. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Battery capacity (kWh)
- 75
- Soc percent
- 20
- Charger power (kW)
- 50
- Efficiency
- 0.9
- Taper start percent
- 80
- Taper end factor
- 0.2
- Energy needed kwh
- 60
Knowing when an electric vehicle will reach a full charge is not the same as estimating a flat twenty-to-eighty percent top-up. Pack chemistry, thermal limits, and the battery management system deliberately slow the final stretch so cells stay within safe voltage and temperature windows. This EV time to full charge calculator turns battery capacity in kilowatt-hours, current state of charge, and charger peak power into a realistic duration that includes the slow final taper after the default eighty percent knee. You get energy still needed, constant-phase hours at peak power, taper-phase hours under declining power, and total hours and minutes you can show in a trip planner, depot dashboard, or overnight home-charging schedule.
What the model computes and why the last stretch is slower
Up to the taper start percentage (eighty by default), the model assumes the charger holds its peak kilowatts and the pack accepts that power after an efficiency factor that defaults to ninety percent for conversion and cable loss. Beyond the knee, peak power falls linearly toward a residual fraction of peak at one hundred percent (twenty percent of peak by default).
That linear taper is a transparent engineering approximation of the common constant-current then constant-voltage style slowdown drivers notice on public DC fast chargers and many Level 2 sessions near full. Integrating energy over declining power yields a closed-form logarithm for the taper segment, so the result is exact for the stated curve rather than a coarse average.
What you can do with it
Overnight home full charge by departure time
From evening SOC, pack kWh, and wallbox kW, see whether the car reaches 100% before a morning departure once the final taper is included.
DC fast-charge stop: wait for full or leave early
Compare constant-phase versus taper-phase minutes above 80% on a public stall to decide if waiting for true full is worth the time.
FAQ
How is this different from a simple energy divided by charger power estimate?
A flat estimate assumes constant peak power to 100%. This calculator applies full power only until the taper start (default 80%), then a linear decline to a residual fraction of peak at full, which lengthens the final stretch realistically.
Can I target 80% instead of full?
No. This capability always targets 100% full charge. For arbitrary from/to percent windows without taper, use a range charge-time tool instead.
What if my battery is already at 100%?
No error is raised for an already-full pack.
Why does the last part of the charge take so long?
Because the battery deliberately slows down near full to keep the cells within safe voltage and temperature limits. Past 80 % by default, power falls steadily until it reaches a fifth of the charger's peak at 100 %.
What does the efficiency setting change?
It is the share of charger power that actually reaches the battery. The default of 0.9 assumes 10 % is lost in conversion and in the cable, so a lower value lengthens the session.
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/travel/ev-time-to-full \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"battery_kwh":75,"soc_percent":20,"charger_kw":50}'const res = await fetch("https://api.kit.forhosting.com/travel/ev-time-to-full", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"battery_kwh": 75,
"soc_percent": 20,
"charger_kw": 50
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/travel/ev-time-to-full",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"battery_kwh": 75,
"soc_percent": 20,
"charger_kw": 50
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/travel/ev-time-to-full", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"battery_kwh":75,"soc_percent":20,"charger_kw":50}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"battery_kwh":75,"soc_percent":20,"charger_kw":50}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/travel/ev-time-to-full", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"battery_kwh": 75,
"soc_percent": 20,
"charger_kw": 50
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "travel.ev_time_to_full",
"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 the model computes and why the last stretch is slower
Travel.ev_time_to_full answers one practical question: from the state of charge you have now, how long until the pack reports one hundred percent on this charger. It first computes energy_needed_kWh as battery_kWh times (one hundred minus current SOC) divided by one hundred—the kilowatt-hours that must still enter the cells. That energy is not delivered at a constant rate all the way to full. The response therefore splits constant_phase_hours and taper_phase_hours so you can explain why the last ten or twenty points of SOC dominate session time on high-power stalls, and why many route planners prefer leaving around eighty percent when minutes matter more than absolute full.
Inputs, defaults, validation, and reading the response
Optional efficiency defaults to zero point nine and must sit in the open-closed interval greater than zero through one. Three fields are required and must be finite numbers: battery_kwh (usable pack capacity, strictly greater than zero), soc_percent (current state of charge from zero through one hundred inclusive; aliases current_soc and soc are accepted), and charger_kw (peak charger power in kilowatts, strictly greater than zero). Optional taper_start_percent defaults to eighty and must lie between zero and one hundred. Optional taper_end_factor defaults to zero point two and must be greater than zero and at most one—if it were zero the integral would diverge as power hits the axis at full. When SOC is already one hundred, the capability returns zero hours and minutes with already_full true instead of inventing a negative session. Every other failure throws a typed invalid_input error that names the offending field; failed validation is not billed. On success you receive the echoed inputs, energy_needed_kwh, constant_phase_hours, taper_phase_hours, total hours, total minutes (derived from the unrounded hour total before display rounding), already_full, and a short formula string documenting the integral model. Pair the numbers with your own thermal or battery-chemistry model only if you need vehicle-specific curves; this endpoint stays deliberately charger-and-pack simple so a form, SMS bot, or fleet API can call it without proprietary BMS maps.
Where time-to-full with taper earns its keep on the road and in software
Overnight home charging on a seven-point-four or eleven kilowatt wallbox is often planned against a hard departure time: drivers want to know whether plugging in at twenty percent after a late return still reaches full by morning once the final taper is counted. Road-trip stop planners use the same endpoint when deciding whether to wait for ninety-five or one hundred percent at a DC fast charger or to unplug near eighty and roll, because the taper phase on a fifty, one hundred fifty, or three hundred fifty kilowatt stall can cost more minutes than the constant phase that filled the middle of the pack. Depot and workplace fleet software batch thousands of calls at $0.002 each to schedule shift handovers when every vehicle must leave at a documented full state of charge rather than a partial top-up. Use the defaults for a sensible first estimate, then tune taper_start_percent and taper_end_factor when you have telemetry from a specific vehicle and charger family, and keep the energy and phase breakdown next to the total so operators understand where the minutes went.
Integration use cases
Fleet depot full-charge scheduling
Batch API calls at $0.002 per vehicle to plan overnight depot sessions that must hand over at documented 100% SOC.
Technical questions
What does taper_end_factor mean?
It is the charger power at 100% SOC as a fraction of peak. The default 0.2 means power falls linearly to 20% of peak by full. It must stay greater than zero so the integral remains finite.
What does the EV time to full charge calculator cost?
The browser widget is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.