Marathon Pace Predictor

Weekly distance:

Enter 5-250 in km/week or mi/week, e.g. 80 km/week.

Average training speed:

Use moving speed from aerobic runs, e.g. 10.5 km/h or 6.5 mph.

Runs per week:

Enter whole sessions from 1-14, including long runs and workouts.

sessions

Model adjustment: {{ tanda_adjustment_percent > 0 ? '+' : '' }}{{ tanda_adjustment_percent.toFixed(1) }}%

Range -12% to +12%; positive slows the predicted finish, negative speeds it up.

% {{ adjustmentDeltaDisplay }}

Metric	Value	Copy
{{ row.label }}	{{ row.value }}
Keep in mind {{ index + 1 }}

Marker	Distance	Cumulative time	Segment pace	Copy
{{ split.label }}	{{ split.distanceDisplay }}	{{ split.timeDisplay }}	{{ split.paceDisplay }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A marathon pace target compresses a long race into one average number, but the race itself does not feel average. The distance is fixed at 42.195 km, so every finish goal can be expressed as elapsed time, average speed, pace per kilometer, and pace per mile. The hard part is deciding whether a training block can support that pace when fatigue, heat, fueling, terrain, and pacing choices accumulate late in the race.

Training-based prediction starts from recent running evidence rather than a single wish time. Weekly distance describes the amount of running stress, average training speed describes the normal pace behind that work, and run frequency shows how the load is distributed. Those values should come from the same steady period. Mixing a peak mileage week with a later fast workout can make the target look cleaner than the training record really is.

Several details change how much trust a pace prediction deserves. Easy runs logged too fast can inflate the speed input. Low run frequency can make the same weekly distance harder to absorb. A missing long-run pattern can hide durability problems that do not appear in the equation. Weather, hills, wind, turns, crowding, and aid-station timing can also move the race away from an even-effort plan.

Prediction models are most useful when they set a defendable opening pace and expose questionable targets early. A number that fits the training block can still be adjusted for course conditions. A number that already conflicts with recent long runs, workout effort, or injury history should be treated as a warning, not a goal to force.

Marathon pacing is also a health and execution decision. A calculator can turn training inputs into splits, but it cannot detect illness, heat stress, dehydration, poor fueling, or a medical reason to slow down or stop. Conservative pacing is often the better choice when race-day warning signs appear.

How to Use This Tool:

Enter one consistent training block, review the warning badges, then use the split and chart outputs only if the target still fits the runner and the course.

Enter Weekly distance from a recent steady block. Use the unit selector to match your log, and avoid using a one-week peak as the normal value.
Enter Average training speed from ordinary aerobic running. Do not use only interval pace, race-pace segments, or one unusually fast long run.
Set Runs per week to the number of sessions from the same period as the distance and speed inputs.
Open Advanced only when previous marathon results show a consistent model bias for you. A positive Model adjustment slows the finish and splits; a negative value speeds them up.
Check the summary for finish time, race speed, pace per kilometer, pace per mile, training badges, and any warnings. Fix input errors before using exported data.
Use Race Summary for headline metrics, Checkpoint Splits for cumulative race markers, Pacing Timeline for distance-versus-time review, and Marathon Readiness Map for the sub-4h comparison.
Copy or download CSV rows, DOCX summaries, chart images, chart CSV data, or JSON after the visible summary and tabs match the training block you meant to model.

Interpreting Results:

The finish time is the headline output, but the warning badges decide how cautiously it should be used. A slower estimate with clean inputs may be more useful than a faster estimate built from very low mileage, unusually high or low training speed, or a finish time outside the model's practical range.

Even-effort splits turn one finish estimate into checkpoint times. They are useful for a watch screen, wristband, coach review, or race rehearsal. They are not a promise that the final 10 km will feel like the first 10 km, and they should be adapted for hills, heat, wind, crowding, or a deliberate negative-split plan.

Marathon pace prediction outputs and interpretation
Output	What it shows	How to use it
`Finish time`	Adjusted marathon estimate for 42.195 km.	Compare it with recent workouts, long-run durability, and prior races.
`Average pace`	The constant pace needed to match the finish estimate.	Use it as a first target, then adjust for course and conditions.
`Race vs training speed`	Predicted marathon speed divided by average training speed.	Large ratios need workout and race evidence, not only confidence in the model.
`Checkpoint Splits`	Cumulative times at 5 km, 10 km, 15 km, halfway, 25 km, 30 km, 35 km, 40 km, and finish.	Build a practical pacing card or watch-check list.
`Pacing Timeline`	A distance-versus-elapsed-time chart for the same split plan.	Export it when a visual pace plan is easier to review than a table.
`Marathon Readiness Map`	Weekly distance and training speed plotted against a sub-4h boundary for the selected run frequency.	Use it as a model comparison, not proof that race execution is ready.

The model adjustment changes every derived output together. It is most useful as evidence-based calibration after previous marathons show that the baseline is consistently fast or slow for the same runner. It should not be used to hide warning badges or force a preferred finish time.

Technical Details:

The page uses a transparent training-index equation with normalized units. Weekly distance is converted to kilometers per week, average training speed is converted to kilometers per hour, and run frequency is rounded to whole weekly sessions before the baseline finish time is calculated.

The marathon distance is fixed at 42.195 km. Pace per kilometer and pace per mile are derived from the same adjusted finish time, so changing the model adjustment, distance input, speed input, or run frequency updates finish time, race speed, split rows, charts, and JSON together.

Formula Core

t_{base} = 326.3 + 2.394 T - 12.06 V - 46.1 R

t_{adj} = t_{base} \times (1 + \frac{p}{100})

{pace}_{km} = \frac{t_{adj} \times 60}{42.195}

Marathon pace predictor formula symbols
Symbol	Meaning	Unit
`T`	Weekly distance after unit conversion.	km/week
`V`	Average training speed after unit conversion.	km/h
`R`	Runs per week after whole-session rounding.	sessions/week
`p`	Manual model adjustment.	percent
`tbase`	Baseline finish time before adjustment.	minutes
`tadj`	Adjusted finish time used for pace, speed, splits, charts, and exports.	minutes

The positive coefficient on T means that changing only weekly distance upward can make the baseline slower in this equation. That is model sensitivity, not coaching advice. In real training, volume, speed, long-run structure, recovery, and workouts change together, so one-field tests can produce counterintuitive results.

The sub-4h boundary solves the same baseline equation for the training speed required when tbase = 240 minutes:

V = \frac{326.3 + 2.394 T - 46.1 R - 240}{12.06}

Marathon pace predictor warning thresholds
Warning check	Threshold	Reason for caution
Low weekly distance	`T < 40` km/week	Very low mileage can make a marathon estimate look too usable for the durability required.
High weekly distance	`T > 180` km/week	Very high volume sits outside ordinary recreational planning and should be checked against race history.
Training speed range	`V < 8` or `V > 15` km/h	Unusually slow or fast training speed makes the model less stable as a planning estimate.
Elite-level output	`tbase < 140` minutes	A sub-2:20 estimate needs elite-level evidence beyond the calculator.
Very slow output	`tbase > 330` minutes	Longer finishes are more affected by fueling, walk breaks, heat, and time-on-feet fatigue.

The split table divides the adjusted finish time proportionally across fixed distance markers. Segment pace comes from the distance between adjacent markers, so each row is an even-effort projection rather than a separate fatigue model.

Limitations and Privacy Notes:

The estimate is a planning number, not a race guarantee. It does not measure lactate threshold, running economy, body composition, course profile, heat tolerance, illness, injury risk, fueling, sleep, or taper quality. Any one of those factors can matter more than the equation on race day.

The calculation runs from the values on the page. No training log upload, account connection, or server-side race analysis is required.
The model is most defensible when inputs come from the same recent training period and sit inside the warning ranges.
The chart and split exports contain the training values and predicted times you choose to copy or download.
Medical symptoms, heat stress, severe fatigue, dizziness, chest pain, or injury signs should override any pace target.

Worked Examples:

Building a first pass from a steady block. With T = 80, V = 10.5, and R = 4, the baseline is 326.3 + 2.394 x 80 - 12.06 x 10.5 - 46.1 x 4, or about 206.8 minutes. With p = 0, the finish display is about 03:26:47, with an average pace near 4:54/km or 7:53/mi.

Seeing why frequency affects the result. Keeping the same distance and speed but increasing R lowers the baseline because the run-frequency term is negative. That does not mean adding sessions instantly creates fitness; it means the equation treats frequency as part of the training profile.

Using a personal adjustment. If previous marathons show that the baseline is usually five minutes too fast for you, a small positive adjustment slows the finish, splits, speed, and chart exports together. That is calibration from evidence, not a way to hide weak inputs.

Reading the sub-4h map. A point below the boundary means the selected weekly distance and speed do not line up with a 240-minute baseline at the chosen run frequency. It can help compare training profiles, but it does not replace long-run fueling, weather planning, or disciplined first-half pacing.

FAQ:

Is the predicted finish time a race guarantee?

No. It is a training-based estimate. Weather, course profile, crowding, illness, taper quality, fueling, and pacing mistakes can all move the race away from the calculated number.

Should average training speed include intervals?

Use a typical moving speed for the training block. If you average only fast workout segments, the result can become too optimistic for marathon distance.

Why can more weekly distance make the baseline slower?

The exact equation shown in Technical Details gives weekly distance a positive coefficient. Read one-input changes as model sensitivity checks, not training advice.

Can I work in miles and mph?

Yes. Miles are converted to kilometers and mph is converted to km/h before the equation runs. The results then show pace and distance in both unit systems where useful.

When should I use the model adjustment?

Use it when repeated race history shows a consistent personal bias against the baseline. Avoid using it just to force a preferred target time.

What should I do when warnings appear?

Keep the output as a rough planning number, compare it with recent workouts, and choose a more conservative race plan if the calculated pace is not supported by training evidence.

Glossary:

Average training speed: The typical moving speed from the training block used as the speed input.
Checkpoint split: A cumulative projected time at a race marker such as 10 km, halfway, or 40 km.
Even effort: A pacing assumption where the same average effort is spread across the whole marathon.
Model adjustment: A percentage change applied to the baseline finish time before pace, splits, charts, and exports are derived.
Race vs training speed: The predicted marathon speed divided by the average training speed.
Training-index model: A prediction model that estimates race performance from training-log quantities such as weekly distance, pace, and frequency.
Weekly distance: Total running distance in an average week of the selected training block.

References:

World Athletics Competition and Technical Rules, World Athletics, effective January 1, 2026.
Prediction of Marathon Performance Time on the Basis of Training Indices, Giovanni Tanda, Journal of Human Sport and Exercise, 2011.
Marathon Performance in Relation to Body Fat Percentage and Training Indices in Recreational Male Runners, Tanda and Knechtle, 2013.
Running Speed During Training and Percent Body Fat Predict Race Time in Recreational Male Marathoners, Barandun et al., 2012.