Timecode ↔ Frames Converter

Convert between SMPTE timecode and frame numbers at any frame rate — including drop-frame, where 00:01:00;00 does not exist. Shows the exact duration too.

About this tool

Timecode is a label for a single frame, written hours, minutes, seconds and frames. At 25 fps the last field runs 00 to 24, so 00:00:01:00 is the 25th frame — which is why one second of 25 fps footage is frames 0 through 24, and the frame after 00:00:00:24 is 00:00:01:00. Turning a timecode into a frame number is therefore a base-25-to-base-10 conversion wrapped in a base-60 clock, and doing it by hand is exactly where off-by-one errors live.

The interesting part is 29.97. It is not 30 — it is 30000 divided by 1001, about 29.97003 fps, and it exists because colour television needed to squeeze a frame rate into a channel that was not quite wide enough. Count frames in groups of 30 while the pictures actually arrive at 29.97, and the timecode drifts fast: about 3.6 seconds per hour. Broadcast solved this by skipping numbers instead of pictures. Every minute, except every tenth minute, the timecode jumps from 00:00:59;29 straight to 00:01:00;02. Frames 00:01:00;00 and 00:01:00;01 are simply never used, which is why drop-frame timecode is written with a semicolon instead of a colon.

The consequence is that one hour of drop-frame timecode is 107 892 frames, not the 108 000 you get by multiplying, and it runs for 3599.996 seconds of real time — the point of the whole scheme is that this is close enough to a real hour to not matter. Non-drop timecode at the same rate counts a clean 108 000 frames but runs 3603.6 seconds, so it drifts four seconds ahead of the clock every hour. Which one you need depends on your pipeline, not on preference: broadcast and most delivery specs ask for drop-frame, while editing and effects work usually stays non-drop because frame counting there is simple arithmetic.

Reading a short timecode from the right

A timecode may be written as SS:FF, MM:SS:FF or HH:MM:SS:FF, and the fields are filled in from the right. 12:05 therefore means 12 seconds and 5 frames, not 12 minutes and 5 seconds; the frame pair is always the last two fields.

The shortest accepted form is two fields, seconds and frames; three fields adds minutes, and four adds hours. Reading from the right is what makes the short forms unambiguous, because leaving out minutes while keeping hours would otherwise be indistinguishable from leaving out hours.

The two readings are far apart, which is why it matters. 01:23 at 25 fps is frame 48 taken as one second and twenty-three frames, and frame 2075 taken as one minute and twenty-three seconds. The tool always reads the last pair as frames and leaves every field you did not type at zero.

A colon and a semicolon are both accepted as separators on input, so a timecode pasted from a drop-frame source and one pasted from a non-drop source both work unchanged. What comes back follows the stricter convention: the semicolon appears only when the frame rate you selected counts in drop-frame.

How many frames a drop-frame minute holds

A drop-frame minute holds 1798 frames rather than 1800, because two numbers are skipped at its start. A ten-minute block holds 17982 frames and an hour holds 107 892 — 108 numbers fewer than multiplying would give.

The rule is that every minute except every tenth minute loses its first two timecode numbers, so 00:01:00;00 and 00:01:00;01 never appear on a real deck. Count the frames in one of those minutes and you get 1798: thirty numbers per second for sixty seconds, minus the two that were skipped.

Ten such minutes make a block, and the tenth minute keeps its two numbers, so a block is 1798 × 10 + 2 = 17982 frames. Six blocks make an hour, which is why the tool reports an hour of drop-frame as 107 892 frames with 108 skipped numbers — the same as 108 000 minus six times eighteen.

The scheme exists because 1798 is not a fudge but the arithmetic of the rate. At 29.97 fps, 1798 frames take almost exactly one real minute, so an hour of drop-frame timecode runs 3599.996 seconds, four milliseconds short of the clock. Non-drop counting at the same rate runs 3603.6 seconds, three and a half seconds ahead, and that is the drift the mechanism was invented to remove.

Which frame rates offer drop-frame counting

Only the 29.97 and 59.94 families have a drop-frame variant, and the rate list offers each of them twice, once counting every number and once skipping. The other six rates, including 23.976, never skip a number.

The list holds ten rates. Four of them are the two 1001-based rates in both counting modes: 29.97 drop-frame and 29.97 non-drop, and the same pair at 59.94. The remaining six — 23.976, 24, 25, 30, 50 and 60 — have no drop-frame entry and count every number.

That 23.976 has no drop-frame variant is worth being precise about, because it is a 1001-based rate just like 29.97 and it drifts by the same proportion: counted at 24 frames per nominal second, an hour of it runs about 3.6 seconds long. What differs is the counting base, 24 rather than 30 or 60. Twenty-four counted frames at this rate take 1.001 seconds, and the duration shown reflects that.

The two entries in a pair are not interchangeable, and they are also never different footage: swap the rate and the same label returns a different frame number while the pictures stay frame for frame identical. Which of the two is right is a question about your delivery specification rather than about the video, so it is worth checking rather than assuming.

Drop-frame relabels the count, it does not retime the footage

An hour of drop-frame timecode at 29.97 is 108 frame numbers shorter than non-drop. That gap is 3.6 seconds of labelling drift, and nothing about the recording changes.

01:00:00;00 in drop-frame is frame 107,892, while 01:00:00:00 in non-drop is 108,000. The 108 missing numbers are the two skipped in every minute except each tenth, across the 54 minutes of an hour that get corrected.

At 59.94 the same correction doubles. Four numbers are skipped per minute instead of two, so an hour is 215,784 against 216,000, again 216 numbers and again 3.6 seconds. The rule scales with the frame rate because the underlying ratio, 1000 over 1001, does not change.

What makes it purely a labelling scheme is that both modes run at 30000/1001 frames per second and both describe the same recording. Drop-frame exists so that the timecode clock agrees with the wall clock; without it the count falls behind real time by about 3.6 seconds an hour, which matters the moment a programme has to hit a fixed start time.

Frequently asked questions

What is the difference between drop-frame and non-drop?

Drop-frame skips two timecode numbers at the start of most minutes so that elapsed timecode stays close to elapsed real time at 29.97 fps. Non-drop counts every number and therefore drifts about 3.6 seconds ahead per hour. Neither changes the pictures — the footage is identical, only the labels differ. Switch the frame rate between the two 29.97 entries to see both answers for the same input.

Why does it say my timecode does not exist?

Because in drop-frame it does not. 00:01:00;00 and 00:01:00;01 are the skipped numbers; the first minute of drop-frame starts at 00:01:00;02. A formula that multiplies blindly will happily return a frame number for a label that can never appear on a real deck, which is why this tool refuses instead.

Should I use 29.97 or 30?

They are different sources. 30 fps is a true integer rate, common for screen recordings and some web delivery. 29.97 is the 30000/1001 rate inherited from NTSC broadcast. Use whichever your source actually is — if a capture card reports 29.97, treat it as 29.97, and note that every conversion at that rate is about 0.1 percent off if you round it to 30.

Why is the duration not a round number?

Because the frame rate is not round. One hour of drop-frame timecode is 107 892 frames, and 107 892 divided by 29.97003 is 3599.9964 seconds — just under an hour, which is the design working as intended. Frame rates are converted here as exact fractions, 30000 over 1001 rather than 29.97, so long durations do not accumulate a rounding error.

Does anything I type get sent anywhere?

No. The conversion is plain arithmetic in the page. There is no server, no request and no logging, and the tool keeps working with the network switched off.

Related tools