| Metric | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
| Checkpoint | Cumulative Time | Copy |
|---|---|---|
| {{ s.label }} | {{ s.time }} | |
| No splits yet. Add distance, time, and split size to see pacing checkpoints. | ||
| Race | Distance | Projected time | Projected pace | Delta vs current |
|---|---|---|---|---|
| {{ row.race }} | {{ row.distance }} | {{ row.projectedTime }} | {{ row.pacePerKm }} | {{ row.delta }} |
Running pace is the practical language of effort because it turns one finish time into repeatable checkpoints that can be carried into a workout, race plan, or treadmill session. The stakes are simple but real: a target that is only a few seconds per kilometre too ambitious can unravel over longer distances, while a target that is too conservative can leave the session mis-set from the start.
This calculator translates the same effort across pace, speed, and projected race time without forcing you to do the conversions manually. Enter a distance and a finish time, or back-calculate the time from a target pace or target speed, and the page produces pace metrics, cumulative splits, equivalent-race projections, a pace-versus-speed map, and a JSON export of the whole calculation state.
That makes it useful in more than one setting. A runner can turn a recent 10 km result into kilometre splits for a threshold session. A coach can check how a pace target looks in both min/km and mph. Someone moving between road training and treadmill running can keep the same effort anchored while swapping the unit system underneath it.
The tool is also honest about what kind of answer it gives. The projection ladder is a model built from one known performance and a chosen fatigue exponent. The pace-speed chart is a package-defined map around the current average effort. Neither view knows whether the course is hilly, whether the weather is punishing, or whether the athlete fades late in long races.
What this does not mean is physiological profiling. The page can organize pace information, but it does not estimate lactate threshold, critical speed, fitness readiness, or training load. It is strongest as a conversion and planning aid, not as a promise about what will happen on race day.
The best place to start is the reference effort itself. Choose a preset or enter a custom distance, then give the page either the total time or a target pace or speed that can be converted into total time. Once distance and total time are both positive, every result surface on the page becomes readable from the same underlying effort.
Pace Metrics is the quickest trust check because it shows the reference effort in both pace and speed terms, plus the same distance in kilometres and miles. If those primary rows look wrong, do not trust the rest yet. Correct the unit system or total time first. The split table and projection ladder only become useful after the core pace-speed translation is believable.
Splits is the most practical tab for execution. It answers the question, "What clock time should I see at each checkpoint if I actually hold this average?" The chosen split distance can match the race unit, switch to the other road unit, or use metres for shorter interval-style checkpoints. A finish row is always included, so the table works as both a pacing ladder and a sanity check against the total time.
Race Projection Ladder is best read as a comparison tool. The custom-goal row is useful when you are testing how one recent result translates to a half marathon, marathon, or another training target. It becomes less trustworthy as the target distance moves farther away from the reference effort or when the projection profile changes the answer sharply.
The chart is the quickest visual cue, not the final word. Pace-Speed Map shows the current effort as a point on a speed-versus-pace curve and overlays package-defined pace zones around that point. It is helpful for orientation, but the splits table and the primary pace row should still be the deciding numbers when you need a pace you can actually follow.
The base calculation is a straight conversion between distance and elapsed time. The package stores total time in seconds, converts the entered distance to kilometres and miles, then derives average pace and average speed from those normalized quantities. Pace is time per unit distance. Speed is distance per unit time. Both views describe the same effort; they are simply inverted expressions of it.
Unit switching is synchronized rather than cosmetic. When the user moves between kilometre and mile systems, the page converts the entered distance, the target pace fields, and the target speed field so the underlying effort stays coherent. This matters because a plan written in min/km can look numerically unrelated once it is displayed as mph, even though the effort is unchanged.
Split generation is built from the normalized kilometre distance. The chosen interval is converted to kilometres, cumulative checkpoints are laid out at that spacing, and each checkpoint time is rounded to the nearest second. The finish is always appended as the last row, and the script caps intermediate splits at 500 so tiny split sizes do not produce an unusable table.
The projection ladder uses a Riegel-style power relation. The package exposes three fixed exponents: 1.04, 1.06, and 1.08. Lower values assume endurance carries better to longer events, while higher values assume more slowdown as the target distance grows. The page applies the chosen exponent to standard targets such as 5K, 10K, 10 miles, half marathon, marathon, and the user-defined goal row.
The chart is an interpretation layer on top of the same effort. It calculates a package-specific speed range around the current average result, then labels pace bands relative to the current pace rather than against universal training zones. This is why the chart can guide comparisons without pretending to diagnose fitness or prescribe a training system.
| Profile | Exponent | How the result changes |
|---|---|---|
| Endurance-leaning | 1.04 | Longer-race projections stay flatter and faster relative to the reference result. |
| Balanced | 1.06 | Acts as the page's middle-ground projection profile. |
| Speed-leaning | 1.08 | Longer-race projections slow down more aggressively as distance increases. |
| Band | Pace window relative to the current average pace | What it means here |
|---|---|---|
| Race push | Faster than 90% of current pace time | A clearly faster effort than the reference run. |
| Target pace | Between 90% and 103% of current pace time | Close to the reference effort entered in the form. |
| Steady effort | Between 103% and 118% of current pace time | A moderate slowdown relative to the reference result. |
| Easy / recovery | Between 118% and 135% of current pace time | A meaningfully slower effort used here as a recovery-oriented comparison. |
Apply to back-calculate it.Pace Metrics first, then confirm checkpoint times in Splits.Race Projection Ladder, Pace-Speed Map, and the JSON export when you need a broader planning view or structured output.The most trustworthy rows are the ones derived directly from the entered effort. Pace (per km), Pace (per mile), Speed (km/h), and Speed (mph) are all immediate translations of the same distance-time pair. If the planning goal is simply to know what pace equals what speed, those rows are the answer.
The split table is the most actionable output because it converts that average effort into clock checkpoints. A split plan is only as realistic as the average effort behind it, but once the reference effort is credible, the split rows are the easiest numbers to carry into a race band, treadmill display, or workout card.
The projection ladder should be treated with more skepticism. It is useful for comparison, especially when the target distance is reasonably close to the reference distance. It becomes less reliable when the jump is large, when course conditions differ, or when a change in exponent moves the answer noticeably. A sensitive projection is a signal to stay conservative, not to hunt for the most flattering row.
The chart is easiest to read if you remember that pace is inverted there. A point higher on the chart is faster because the pace axis counts minutes per unit distance. The chart's labels are therefore best treated as orientation aids around the current effort rather than as evidence that one colored band is objectively right for every runner.
Enter 10 km and 00:50:00, then leave the split distance at 1 km. The page produces a primary pace of 05:00 / km and a speed of 12.00 km/h. The split table then lays out each kilometre checkpoint at five-minute intervals until the finish.
That is a useful case because the projections are secondary and the split ladder is the real deliverable. You can take the kilometre rows directly into a workout or race pacing sheet without doing any additional conversion.
Choose the half marathon goal distance, leave the total time empty, and enter a target pace of 05:15 in the current unit system. When you press Apply, the page calculates the total time from that pace and fills the downstream metrics automatically.
This is valuable when you know the effort you want to hold but not the finish time it implies. Instead of solving the time manually, the page converts the target pace into a full result set you can sanity-check against the split table and chart.
Start from a recent 5 km result and project it to a marathon. With the endurance-leaning profile, the projected marathon stays comparatively fast. Switch to the speed-leaning profile and the marathon row slows because the model assumes greater fatigue over the longer distance.
That contrast is the reason the profile control matters. The projection is not one immutable truth. It is a model choice layered over the same reference performance, and large swings between profiles are a warning to treat the long-distance projection cautiously.
Use whichever view matches the environment. Road and track work usually feels more natural in pace, while treadmills often display speed first. The page keeps both views tied to the same effort so you do not need to choose only one.
Because the page converts the whole reference effort, not just the label. Distance, pace, and speed are synchronized so the underlying run stays consistent after the unit switch.
No. They are model outputs based on the reference effort and the chosen exponent. Weather, terrain, fuelling, pacing discipline, and durability over longer distances can all make the real result slower or faster.
The script caps intermediate split rows at 500 so the page remains usable. If you need fewer rows, increase the split interval. If you need more precision than the page will show, use the JSON export and continue downstream.
No dedicated scoring backend is involved here. The calculations, chart data, split rows, and JSON payload are generated in the browser after the page loads.