Timecode to Frames Calculator
Convert an HH:MM:SS:FR timecode into an exact total frame number for an integer, non-drop frame rate.
Timecode inputs
Live result
Total number of frames: 12,373.
Frame contribution breakdown
| Component | Input | Frames contributed |
|---|---|---|
| Hours | 0 h | 0 |
| Minutes | 8 min | 11,520 |
| Seconds | 35 s | 840 |
| Frame offset | 13 frames | 13 |
How to use this timecode to frames calculator
What this calculator does. This tool converts a conventional HH:MM:SS:FR timecode into the total frame number counted from 00:00:00:00. It is designed for integer, non-drop frame rates, where every whole second contains exactly the selected number of frames. The calculation is useful when an edit note, render request, VFX handoff, or media log gives you a timecode but another system expects an absolute frame count. It does not implement NTSC drop-frame numbering or fractional rates such as 29.97/59.94 fps; those require a timecode standard that accounts for skipped frame labels. For background on professional timecode conventions, see SMPTE's overview of the Time Code standards family.
When to use it. Use the calculator to translate an editor's marked frame into a render-frame index, compare the same timecode at different integer frame rates, check a frame-accurate cue during conforming, or verify a manually calculated HH:MM:SS:FR position. Adobe's timecode overview for Premiere explains why timecode is used to identify and synchronize moments in a video sequence.
How to calculate. The calculator opens with a complete demonstration: 24 fps and timecode 00:08:35:13, so the live result and the Excel workbook are immediately available. To use your own values:
- Replace Frame rate with your project's integer frames-per-second value.
- Enter the Hours, Minutes, Seconds, and Frames fields from the source timecode. Results update while you type.
- Read Total number of frames first, then use the supporting outputs and Frame contribution breakdown to audit how the total was assembled.
- Select Download Excel to export the current validated inputs, outputs, breakdown, and method to a real .xlsx workbook. Reset clears the demonstration/input data and disables export until you enter a new complete valid state.
Input guide. Frame rate is required and accepts a whole number from 1 to 240 fps; 24 is a typical example. A higher rate increases the frame contribution of every hour, minute, and second, while the final frame offset remains the value typed in Frames. Decimal rates such as 29.97 are rejected rather than silently treated as 30. Hours is a required integer from 0 to 23; for example, 1 represents one full hour from the zero timecode. Minutes and Seconds are required integers from 0 to 59; values such as 75 must be normalized before entry rather than interpreted as 1 minute 15 seconds. Frames is the within-second frame index, required from 0 through frame rate minus 1. At 24 fps, valid frame offsets are 0-23. Entering 24 in that field is invalid because it belongs to the next whole second. All five fields use plain base-10 integers only: grouping commas, percent signs, unit text, decimal commas, and scientific notation are rejected so pasted values cannot be misread.
Output guide. Normalized timecode restates the validated input as zero-padded HH:MM:SS:FR. Total number of frames is the exact absolute frame count produced by this non-drop integer-rate identity. Elapsed whole seconds is hours × 3,600 + minutes × 60 + seconds. Frames from whole seconds multiplies that elapsed-second value by Frame rate. Frame offset is the final FR component added after the whole-second conversion. The three header pills repeat Frame rate, normalized Timecode, and Elapsed seconds so the current scenario remains visible at a glance. In the Frame contribution breakdown, the Component column identifies hours, minutes, seconds, or the frame offset; Input shows the entered quantity with its unit; and Frames contributed shows the exact number of frames each component adds. Zero means that component contributes nothing; larger time components contribute proportionally more frames.
Worked example. The startup timecode 00:08:35:13 at 24 fps contains 8 × 60 + 35 = 515 whole seconds. Those whole seconds contribute 515 × 24 = 12,360 frames. Adding the frame offset of 13 gives 12,373 total frames. The breakdown therefore shows 11,520 frames from eight minutes, 840 from 35 seconds, 13 from the frame offset, and zero from hours. The displayed result, table, and startup Excel workbook all use these same canonical values.
Learn more. Integer non-drop conversion is deliberately simpler than fractional-rate broadcast timecode. Apple's archived QuickTime timecode documentation discusses the distinction between whole-number systems such as 25 fps and NTSC-related fractional rates such as 29.97 fps. If your source uses 29.97/59.94 or a semicolon drop-frame notation, use a tool or NLE setting that explicitly supports that timing system rather than substituting a rounded frame rate here.
Formula and interpretation
Total frames = (hours × 3,600 + minutes × 60 + seconds) × frame rate + frames
The formula treats the first three timecode components as elapsed whole seconds and then adds the final within-second frame index. Because the accepted frame rate is an integer and the FR field must be smaller than that rate, every valid result is an exact nonnegative integer. This makes the output appropriate for frame-index workflows that count continuously from zero timecode without drop-frame label corrections.
Common mistakes to avoid
- Confusing frame rate with the Frames field. Frame rate describes how many frames fit in each second; Frames identifies the current frame inside one second.
- Using fractional NTSC rates as though they were integer timecode. 29.97 and 59.94 workflows may use drop-frame or non-drop conventions that need explicit treatment.
- Entering unnormalized minutes or seconds. Timecode components conventionally stay within 00-59 for minutes and seconds.
- Assuming the last timecode number is a free-standing total. FR is bounded by the selected rate; at 24 fps, 00:00:00:24 should be normalized to 00:00:01:00.