Video Timecode Calculator
Convert timecode between frame rates, total the runtime of a whole clip list, convert timecode to frames and seconds, with real drop-frame support at 29.97 and 59.94 fps.
- Free, no account
- No watermark
- No usage limit
About the Video Timecode Calculator
Most free timecode calculators handle the easy half of the job and bail on the hard half. They convert a clean 24 or 30 timecode to frames, add two numbers, and quit right when the work gets real. The two things that actually cost an editor an afternoon are converting a timecode from one frame rate to another and totaling the runtime of a whole assembly, and almost nobody builds those, which is exactly what this page is for. It converts a timecode between any two of the eight common rates, sums a full list of clip durations in one paste, and runs true drop-frame at 29.97 and 59.94. Every bit of it happens in your browser, and a pasted or dropped clip list is kept out of the half of a share link that a server can read.
How to use
- Pick a mode. Frame-rate conversion, total runtime, timecode to frames, frames to timecode, or add and subtract.
- Set the frame rate. In conversion mode this is the source rate, and a second menu sets the rate you are converting to.
- At 29.97 or 59.94, decide on drop-frame. The checkbox only appears at those two rates, since no other rate needs it. Paste a timecode with a semicolon and it turns on for you.
- Enter your values. Paste a HH:MM:SS:FF string straight out of Premiere, Resolve, Avid, or Final Cut, or in total-runtime mode paste or drop a whole list of them.
- Read the result live. No button to press, the answer updates the moment you stop typing.
- Share or embed it. The Share link copies the page with your exact mode, rates, and values baked in, so you can bookmark a setup or send a colleague the finished number. Embed drops the live tool on your own site.
Convert a timecode between frame rates
This is the part I care about most, because it is the question that sends people back to opening a full editor just to read one number. You shot at 25 in Europe and the deliverable is 24 for a US master. Or the audio came in at 23.976 and the picture is a true 24. What does 01:00:00:00 become on the other side? There are actually two right answers, and a calculator that gives you only one leaves out the other half.
The first answer keeps the frames. Every frame you shot is still there, the count does not change, only the label and the playback speed do. That is the pull-up and pull-down world, 24 against 23.976, or a PAL 25 conformed down to 24. The picture plays a hair longer or shorter, and the tool tells you exactly how long in real seconds so you can see what happened to your runtime.
The second answer keeps the running time. If the footage is resampled to hold its duration, the same wall-clock length lands on a different frame count at the new rate, and the tool works out that count and the matching timecode for you.
Ours shows both, side by side, labeled in plain words, so you pick the one your workflow actually did instead of guessing which convention the calculator quietly assumed. That is the whole reason to reach for this instead of doing it by hand with a client waiting.
Total the runtime of a clip list
Adding two timecodes is table stakes. Real editing is not two clips, it is forty, and you need the total runtime before you can tell a producer the reel fits the slot. So paste a whole column of durations, one per line, and read the total in one shot. A clip name or an event number in front of the timecode is fine, it grabs the timecode and ignores the label.
Drop in an EDL and it reads differently, because an EDL row is not a duration. Every event carries four timecodes and the last two are record in and record out, positions on the master rather than lengths. Total those and a forty event reel cut from a one hour master comes back as roughly forty hours. So the tool reads the record columns and returns the span from the earliest in to the latest out, which is the runtime you were asking for, and it says on screen that it read the file that way. Audio events on their own rows, overlapping dissolves and speed ramps all sit inside that span, so nothing gets counted twice.
The one thing it will not do is guess. Two or three timecodes on a line could be a start and a length or an in and an out, and those total differently, so it leaves the line out and tells you how many it left, along with anything else it could not read.
It works at whatever rate you set, drop-frame included, and reports the sum three ways: as a timecode, as a raw frame count, and as true seconds. That is how you check an assembly against a delivery length to the frame instead of eyeballing it.
Drop-frame, the way SMPTE actually defines it
Drop-frame is the one broadcast editors genuinely need and the one cheap tools skip. When color video arrived in North America the rate could not stay at a clean 30, it slid to 29.97, and timecode that counts as if a full 30 frames play each second runs ahead of the real clock by about 3.6 seconds an hour. Drop-frame corrects that by skipping frame numbers rather than any actual frames, so your picture is untouched. Two labels get skipped at the top of most minutes, except every tenth minute, and across an hour that keeps the count honest against the wall clock. At 59.94 it skips four labels a minute instead of two.
Type a timecode that lands on a label that does not exist, like the top of a minute where those low frame numbers were skipped, and the tool says so rather than returning a wrong number. A semicolon before the frames is the standard mark for drop-frame, so when you paste one out of your editor the tool switches over for you.
The plain conversions are still here
None of the basics got dropped. Turn a timecode into a total frame count for a render log or a VFX plate. Turn a raw frame count back into a timecode. Add or subtract two timecodes to find an out point or an exact duration, with a negative result labeled as such rather than wrapping into nonsense. Every result carries the real running time in seconds next to it, because at 29.97 and 23.976 the timecode clock and the wall clock are not the same thing, and treating them as one is how sync drifts over a long program.
Frequently asked questions
Which frame-rate conversion answer do I want, same frames or same time?
If you are doing a straight speed change, 24 to 23.976 or a 25 conformed to 24, you want the same-frames result, because no frames are added or removed, they simply play at a new rate. If the footage was retimed or resampled to hold its length, you want the same-time result. When you are not sure which your editor did, compare the source clip's new duration against the seconds the tool reports for each option, and the one that matches is your answer.
Does converting 25 to 24 change the audio pitch?
The timecode math itself does not touch audio, it only reports the new labels. But the speed change behind a 25 to 24 conform shifts pitch by about 4 percent unless you correct it, which is why a PAL film transfer usually gets a deliberate audio pull. Read the same-frames runtime here first, then pull or pitch-shift the audio to match that new length.
Why does my runtime total come out a frame off from the sequence?
Nine times out of ten it is the inclusive out point. Many systems count the marked out frame as the last frame you keep, so a clip's true length is the end minus the start plus one frame. If you built the list from raw in and out points instead of durations, add a frame per clip, or paste the durations your editor already reports.
Can I mix frame rates in one runtime total?
No, and you would not want to. Every line is read at the single rate you set, because a frame is a different slice of time at 24 than at 30, so adding raw counts across rates gives you a meaningless number. Convert each clip to your master rate first, then total them.
What file types can I drop into the runtime list?
Plain text, CSV, and EDL exports all work, along with anything you can paste as text. A row carrying one timecode is read as a duration no matter what else is on it, so a spreadsheet line with a clip name and a reel number still counts. An EDL is spotted by its four timecode columns and read as a timeline instead. Whatever gets skipped is tallied by reason, so you can see whether a row was a header, an ambiguous pair, or a timecode that does not exist at the rate you set.
Is 23.976 really identical to 24 for the labels?
For the frame labels, yes, both run the frame field 0 to 23. The difference is real time. A frame at 23.976 lasts a touch longer than one at a true 24, so the running seconds come out slightly higher, and over a feature that gap adds up. Set the rate to what was actually shot so the seconds and any conversion stay accurate.
Does any of this get uploaded to a server?
Not the list. Every conversion runs in your browser as you type, and that includes a file you drop in, which is read locally. Close the tab and it is gone. No sign-up, and no limit on how many you run.
Share and Embed are the part worth knowing exactly, because a link has two halves and only one of them travels. The runtime list goes after the #, which browsers never send, so it is in no access log, no CDN log and no Referer header of ours. The single timecodes and the frame rates go before it, in the plain query, because those are the calculation and they reach our server like any other page setting. What the fragment does not do is make a link private: the list is still inside the link text, so whoever you send it to can read it, and that is why the Embed code leaves it out altogether.