Why it exists
Post-production forums have a recurring thread that goes roughly: someone’s drop-frame math is off by a frame or two near a minute boundary, they cannot see why, and the eventual answer is always the same — the minute-divisible-by-ten exemption was missed, or the sign of the correction was backwards. It comes up often enough that at least one editor has publicly asked a major NLE vendor to simply build a correct drop-frame calculator into the application, and independently, at least five different open-source libraries exist purely to solve this one arithmetic problem, each written from scratch by a different author. That is a strong signal that the problem is real, recurring, and not obvious to get right by re-deriving it under deadline pressure.
It also happens to be a problem a general-purpose chatbot answers unreliably. Ask one to compute a drop-frame timecode addition across a minute boundary and you will often get a confident, plausible-looking, wrong answer — because the correct rule (skip two frame numbers per minute, except minutes divisible by ten) is a small piece of stateful logic, not the kind of fact a language model reliably reconstructs term by term. A calculator that actually runs the arithmetic, rather than predicting what the arithmetic probably looks like, is the more trustworthy source for a number you are about to put in an edit decision list or a delivery report.
The field is also less crowded than it looks. Search for a dedicated drop-frame timecode calculator and the results are dominated by general reference pages that state the rule without a working tool attached, or by calculators bundled as one feature deep inside a much larger production-tools suite. The dedicated tools that do exist tend to be small, unmaintained side projects with no visible history of updates. That gap — real, recurring demand from working editors, a well-defined and independently-solved arithmetic problem, and no well-established dedicated destination for it — is the actual reason this exists as its own tool rather than a feature bolted onto something else.
Built the same way as the rest of this site
No framework, no build step, no analytics, no dependency on anything that could go
offline or change its API under this tool. The conversion logic lives in one file with no
DOM references at all, so it can be — and was — run and tested directly under
Node.js, completely separately from the page that displays it. The interface logic lives in
a second file that only ever writes to the page through textContent, never by
assembling an HTML string, so a timecode typed with stray characters in it renders as those
literal characters rather than being interpreted as markup. Splitting the two apart is what
made the large-scale cross-check described below practical in the first place: the logic
file has no notion of a browser, a button, or an event, so testing it is just calling
functions with numbers and comparing the results.
What it does
- Converts timecode to a frame number and back, at ten frame rates: 23.976, 24, 25, 29.97 (drop-frame and non-drop-frame), 30, 50, 59.94 (drop-frame and non-drop-frame), and 60.
- Shows real elapsed time against the timecode reading, with the drop-frame-versus-non-drop-frame drift made explicit rather than left implicit.
- Does arithmetic: add or subtract a frame count or a second timecode, or compute the duration between two timecodes, all drop-frame aware.
- Reinterprets a frame index at another rate, with an explicit note on what that operation does and does not mean for an actual conform.
- Accepts sloppy input — any of
:,;,.or,as a separator — and always displays the conventionally correct one for the selected rate. - Names invalid input specifically: a frame number outside the rate’s
range, or a dropped frame number typed into a non-exempt minute, produces a message
explaining exactly what is wrong, never a blank result or a silent
NaN.
How the drop-frame arithmetic was verified
The core formula is closed-form — a single expression, not a loop over frames — which is what makes conversion instant even for very large timecodes. But a closed-form formula can be subtly wrong and still produce plausible-looking output for the ranges you happen to test by hand. So the verification here does not stop at “convert a value and convert it back”, which only proves the two directions agree with each other, not that either is correct.
Instead, a second implementation was built using a completely different method: a frame-by-frame simulator that starts at frame zero and steps forward one frame at a time, applying the rule directly in the way a person would follow it with a physical counter — increment the frame field, carry into seconds, carry into minutes, and the instant a new minute begins that is not a multiple of ten, jump the frame field straight from zero to the drop count. That simulator and the closed-form formula were run against each other across 2,529,504 individual frames — four continuous hours each at 29.97 and 59.94 drop-frame, plus sanity ranges at every other supported rate — checking both that the two produce the same timecode for every frame number and that converting a simulated timecode back to a frame number returns the original index. There were zero disagreements.
On top of that comparison, the specific reference values commonly quoted for drop-frame
timecode were checked explicitly: 00:00:59;29 plus one frame equals
00:01:00;02; 00:09:59;29 plus one frame equals
00:10:00;00, because minute ten is exempt from the drop; ten minutes of 29.97
drop-frame timecode is exactly 17,982 frames; one hour is exactly 107,892 frames at 29.97
drop-frame and exactly 215,784 frames at 59.94 drop-frame; and one hour at a plain 30 fps
non-drop-frame is exactly 108,000 frames. Every one matched.
Why real time and the drift get their own tab
Most timecode explanations state that drop-frame “corrects for” the
29.97 rate without showing the actual numbers, which leaves the whole subject feeling like
folklore rather than arithmetic. This tool instead computes, for any timecode you enter, both
the exact real elapsed time (using the true 30000/1001 or 60000/1001 fraction) and the
literal reading of the HH:MM:SS digits, and shows the difference between them
directly. At a drop-frame rate that difference stays under a few milliseconds; at a
non-drop-frame rate it grows at roughly 3.6 seconds per hour. Seeing the number, rather than
being told the rule exists, is the point of that tab.
What it deliberately does not do
- Read video files or embedded timecode metadata. This is a calculator for the numbers you already have or need, not a media parser.
- Conform or retime footage. Frame-rate conversion here relabels a frame index; it does not resample audio, interpolate frames, or add or remove pulldown. That is a job for an editing or transcoding application, informed by what this tool tells you the numbers become.
- Invent a drop-frame rule where none exists. 24 fps and 25 fps have no drop-frame variant, because their true rate has no fractional drift to correct — see the FAQ on the main page for why.
- Model tape-era discontinuities. Reel changes, timecode breaks and non-continuous sequences are real complications in professional post-production that this tool does not attempt to simulate; it assumes a single continuous count.
Privacy and cost
Every conversion runs client-side, as plain JavaScript in your browser tab. What you type is never transmitted, logged or stored — there is no upload endpoint on this page and no code capable of using one. There is no account and nothing to install. Once the page has loaded, nothing further is fetched, so it keeps working with the network disconnected.
The site is free to use. It may carry advertising to cover hosting; see the privacy policy for what that would mean. An advertising script is third-party code that makes its own requests, but it cannot see the contents of a field it did not create, so “what you type never leaves your device” is a claim that survives it.
Corrections
If this tool produces a timecode or frame count that disagrees with a value you know to be correct from a specification, an NLE, or a piece of broadcast equipment, that is worth hearing about. Please include the exact rate, the exact timecode or frame number, and what you expected instead. The contact page has the address.