Convert Non-Drop-Frame Timecode to Drop-Frame
Or paste subtitle text
Options
30 fps non-drop and 29.97 drop-frame write the same clock differently, and this box picks which way the file is read and which way it is written back. A cue one hour in reads 01:00:00,000 under one and 01:00:03,600 under the other — the two are 3.6 seconds apart per hour, not a rounding error. The page's title names one direction, and this box offers only that one, so the file you get is the file the page is about. Nothing about the text changes: no cue is retimed against the video, no frame rate is converted, and a cue inside the first minute of an hour comes back exactly as it went in, because no frame label is dropped there.
Which frame rate the timings are counted in. On the format pages this is what MicroDVD needs, because it stores timing as frame numbers. On the frame rate pages it is the rate the file was timed against — the version the subtitles were made for — and the page's second box takes the rate of the video you are going to use them with. 23.976, 24, 25, 29.97, 30, 50, 59.94 and 60 are the common ones. Getting it wrong shifts the whole timeline, and on the frame rate pages it shifts it by a ratio rather than by a fixed amount.
This page re-labels every timecode in a subtitle file from 30 fps non-drop-frame to 29.97 fps drop-frame. Drop in the file, run it, and each cue's start and end come back written the other way. The words, the cue numbers, the order of the cues and the line breaks are the file's own and are left exactly as they were.
The two conventions spell the same clock differently, and a file has to be in the one the rest of the pipeline is in. Drop-frame counts 30 labels a second but skips two of them every minute except every tenth, which is how it stays with the wall clock while non-drop slowly falls behind it. An hour in, the two are 3.6 seconds apart: 01:00:00,000 under non-drop is 01:00:03,600 under drop-frame. That gap is not a rounding error and it does not get rounded away — it grows with the programme, reaching 36 seconds at ten hours.
Nothing in the first minute of an hour moves, because no label is dropped there and both conventions spell that stretch identically. That is true of clocks that already sit on a 30 fps frame tick — 00:00:02,000 is one — and a clock that sits between two ticks is moved to the nearest one, by up to 17 milliseconds. Reading a clock as a timecode always snaps it to the frame grid, everywhere in the file; inside the first minute the snap is the only thing that moves. A subtitle file's times usually come from a frame-accurate tool and are already on the grid, which is why that stretch often does come back byte for byte.
No subtitle format read here has a field that records which convention a clock is in — SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON and CSV all just write a time. So this page changes the numbers, and which convention they mean stays a property of your pipeline, exactly as it was before the file arrived. What is not in the file cannot be written into it, and pretending otherwise would be worse than saying so.
This is not a frame rate conversion. A file timed for 25 fps video is not retimed here, and nothing is stretched or squeezed against a video: the timings keep their spacing and only the way they are spelled changes. If what you need is the other job — a subtitle file whose spacing follows a different frame rate — that has a page of its own. Nothing is uploaded either: the file is read and written inside the browser tab, so material that cannot leave the machine stays on it.
Examples
A file five minutes in
Input
1
00:05:00,000 --> 00:05:02,000
The room is dark.
2
00:10:00,000 --> 00:10:03,000
A cold night.
Output
1
00:05:00,333 --> 00:05:02,333
The room is dark.
2
00:10:00,600 --> 00:10:03,600
A cold night.
The two cues do not move by the same amount, and that is the whole operation: five minutes in, drop-frame has skipped ten labels, so the clock reads 333 ms later; ten minutes in it has skipped eighteen, so it reads 600 ms later. The text and the cue numbers are the file's own — only the two clock values per cue are rewritten.
The same file an hour in
Input
1
01:00:00,000 --> 01:00:03,000
An hour into the programme.
Output
1
01:00:03,600 --> 01:00:06,600
An hour into the programme.
At one hour the two conventions are 3.6 seconds apart, which is 108 skipped labels. This is the number to compare against if you are checking the page: read the first line of the output and it should be exactly 3600 ms later than the first line of the input. Both edges of the cue move, so the cue keeps its length.
A cue inside the first minute
Input
1
00:00:02,000 --> 00:00:04,000
Nothing to re-label yet.
2
00:05:00,000 --> 00:05:02,000
This one does move.
Output
1
00:00:02,000 --> 00:00:04,000
Nothing to re-label yet.
2
00:05:00,333 --> 00:05:02,333
This one does move.
The first cue comes back byte for byte and the second one moves, in the same run. During the first minute of an hour no label is dropped, so both conventions spell those sixty seconds identically — and 00:00:02,000 is already on a 30 fps frame tick, so nothing about it changes. A clock sitting between two ticks would be nudged to the nearest one instead, by up to 17 ms, which is the same snap the page applies everywhere in the file. Seeing one cue unchanged next to one that moved is the expected result here, not a half-finished run.
Frequently asked questions
What is the difference between drop-frame and non-drop-frame timecode?
Both count 30 labels per second, but 29.97 fps does not deliver 30 frames per second — it delivers about 29.97, so a clock that counts 30 labels a second slowly loses ground against real time. Drop-frame fixes that by skipping two labels at the start of every minute except every tenth minute: the labels are thrown away even though the frames are not. Non-drop keeps every label and drifts. Written down, the two look like the same kind of number; read against the same frame, they are 3.6 seconds apart after an hour and stay further apart the longer the programme runs.
Why does a cue an hour in come out 3.6 seconds later than it went in?
Because 3.6 seconds is what an hour of skipped labels comes to: 2 labels a minute for 54 minutes out of every 60, at 33.37 ms a label, which is 108 labels or 3600 ms an hour. The page is not adding a delay — it is writing the same frames under the other convention, and the other convention reads later at that point in the programme. A cue at 01:00:00,000 goes in and 01:00:03,600 comes out; both of its edges move, so the cue keeps its length to the millisecond.
Why did the first minute of my file come back unchanged?
Because no label is dropped during the first minute of an hour, so drop-frame and non-drop-frame spell that stretch identically — 00:00:02,000 means 60 frames under both, and 60 frames is written the same way either way. The drift starts at the first minute boundary and then grows. There is one other thing that can move a time in that stretch: reading a clock as a timecode snaps it to the nearest 30 fps frame tick, so a value that sits between two ticks, such as 00:00:02,010, comes back as 00:00:02,000. Times copied from a frame-accurate tool are already on the grid and do not move at all.
Which direction do I need — non-drop to drop-frame, or the other way?
It depends on what the timecodes in your file were read off. If you took the timings from a player or an editor set to non-drop and the pipeline you are delivering into works in drop-frame, this is the page. If your file was stamped against a drop-frame display and the tool downstream expects non-drop, you want the other page, which moves the clocks the other way by the same 3.6 seconds an hour. A quick way to tell them apart: run the file here and compare one cue — if the output clock reads later than the input, this direction was the one it needed.
Does this page change the frame rate of my subtitles?
No. Nothing is scaled and nothing is stretched: a cue that was two seconds long is still two seconds long, and the spacing between cues is unchanged, because every cue moves by an amount that depends on where it sits rather than by a ratio. A file timed for 25 fps video is not converted to 29.97 here either — the box that takes a frame rate exists because MicroDVD stores its timings as frame numbers and cannot be read without one. Converting the spacing of a file from one frame rate to another is a different operation with its own page.
Does the file say anywhere that its timecodes are now drop-frame?
No, and no format read here could: SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON and CSV all store a time and nothing about how it was counted. That was already true of the file you dropped in. So the page changes the numbers and which convention they mean remains what your pipeline says it is — the same arrangement you had before, now with the numbers matching it. If a downstream tool has its own drop-frame setting, that setting is what reads these values.