Convert Video Frame Rate

Change a video's frame rate in your browser, from 60 down to 30, 25 or 24 fps for an editing timeline or a smaller file. Free, private, no upload.

🌐 Español

Drop your file here (.mp4, .mov, .m4v, .webm)

🔒 Private by design: your files are processed locally in your browser and never uploaded to any server.

Seven target rates, and the one your project actually wants

The Target frame rate menu offers 23.976, 24, 25, 29.97, 30, 50 and 60 fps, with 30 preselected because that is what most web and social uploads expect. The two fractional entries are the ones people hesitate over. They are the NTSC rates that North American broadcast and plenty of camera firmware still run on, and they are not cosmetic decimals: the tool passes ffmpeg the exact rationals 24000/1001 and 30000/1001 rather than a rounded number, because rounding drifts against the audio clock over a long recording.

If you are not sure what your source is running at, find out before you convert. Video Info Viewer reads the container headers and reports the frame rate alongside the codec, resolution and bitrate, and it is strictly read-only, so it never writes anything back to your file.

What the inspection pass decides before any encoding starts

Every run begins with a bare ffmpeg -i over your file, and the stream dump it prints is parsed by the same function the video merger uses on its own inputs. Two answers come out of it, and both change what happens next.

The first is your source’s real frame rate. If it lands within 0.01 of the rate you picked, the run stops there rather than re-encoding a file to the state it was already in. That tolerance is narrow on purpose: the dump rounds to two decimals, so a true 23.976 source prints as 23.98, while the closest pair of genuinely different rates on the menu is 29.97 against 30, which are 0.03 apart. If the frame rate cannot be read at all, the guard steps aside and the conversion runs, because it exists to save you a pointless encode and not to block the tool.

The second answer is your audio codec, which decides whether the sound is copied or re-encoded. That is covered further down.

Dropping frames on the way down, duplicating them on the way up

The picture goes through ffmpeg’s fps filter, which keeps duration and audio sync intact and works frame by frame rather than buffering a decoded copy of your clip, which matters when the whole thing is running inside a browser tab’s memory.

Going down, the surplus frames are dropped by timestamp. At 60 to 30 that is exactly every other frame, so motion stays even instead of lurching. Every frame that survives is an original, unblended frame, which is precisely what an editor wants when a clip has to sit on a fixed-rate timeline. Going up, frames are duplicated to fill the new slots. Nothing is invented, and this page would rather say so than sell you a smoothness upgrade the math cannot deliver.

From dropzone to a finished MP4

  1. Drop your clip into the box, or click Choose a file. MP4, MOV, M4V and WEBM are accepted, and anything else is refused right there with a message listing those four extensions. An MKV or AVI needs a container conversion first, through Convert MKV to MP4 or Convert AVI to MP4.
  2. Open Target frame rate and pick your rate. 30 fps for the web, 24 or 23.976 fps for a film cadence, 25 fps for a PAL project, 29.97 fps for a North American broadcast deliverable.
  3. Click Convert Video Frame Rate. The button carries the tool’s own name rather than a generic verb, and the bar underneath stays at zero through the inspection pass before it starts climbing.
  4. Download the result. The finished panel also shows the size you put in against the size you got out, with the difference as a percentage.

Cancel is available while the encode runs, but it is a hard stop: it terminates the ffmpeg instance and clears the dropzone, so you re-add the file to try again.

The re-encode itself, and what it costs

The video is encoded with libx264 at CRF 20 on the fast preset, with the faststart flag so a player can read the file’s index without downloading all of it. CRF 20 is a notch better than x264’s own default of 23, close enough to the source that most people will not see the difference on a first watch, but this is still a lossy pass over lossy footage. Our guide on why video re-encoding loses quality covers what that actually does to the frames, and which edits avoid it entirely.

Audio is a different story, because a frame-rate change does not touch it. An AAC track is stream-copied bit for bit into the new MP4. Anything else, which in practice means Opus or Vorbis out of a WEBM and PCM out of a MOV, is transcoded to AAC at 128 kbps. A clip with no audio at all gets an explicit instruction to produce none.

Where a frame-rate change is the wrong lever

Halving the frame rate does usually shrink a file, because the encoder has half as many frames to store, but it is a blunt instrument if size is the actual goal. Compress Video gives you presets aimed at email and chat limits, though note it takes MP4 only, so a MOV needs converting first. If you have a hard ceiling in megabytes, Compress Video to a Target Size is the one built for that, and it takes MOV and WEBM as well.

A frame-rate change is also not a speed change. Slowing a clip down or speeding it up is Change Video Speed, which re-times the stream instead of resampling it and defaults to 2x. And if what you actually want is stills rather than smoother playback, Extract Frames from Video pulls JPGs out of a clip, up to 300 per interval run. The rest of the catalog sits under video tools.

Frequently asked questions

My download came back as clip-24fps.mp4 even though I fed in a MOV. Why the container swap?

A frame-rate change rewrites every frame's timing, so the video has to be re-encoded no matter what you put in, and once that is true there is no original stream left worth preserving in its original wrapper. The module always writes an MP4 and always names it after your file with the chosen rate appended, so beach.mov becomes beach-24fps.mp4 and a 23.976 target gives you beach-23.976fps.mp4. Rename it afterwards if the decimal in the filename bothers your file manager.

I asked for 30 fps on a clip that was already 30 fps and got an error box instead of a video.

That is the deliberate guard, not a failure. Before encoding anything the tool reads your file's real frame rate and compares it against your target with a tolerance of 0.01, and when they match it refuses to spend a full re-encode on a file that would come back looking slightly worse and nothing else. The shell can only show its one generic failure sentence, so the specific reason is written to the browser console instead. Your file stays loaded, so just pick a different target rate and press the button again.

Will my WEBM keep its Opus audio track after the conversion?

No. Opus has no place in an MP4, so it is transcoded to AAC at 128 kbps, which is a second lossy pass on audio that was already lossy. A source that already carries AAC is the lucky case, because that track is stream-copied bit for bit and never touched. A silent clip stays silent, since the encoder is told explicitly that there is no audio stream rather than being pointed at one that does not exist.

Why does the progress bar sit at zero for so long before it starts moving?

Two separate things happen before the first progress event fires. On the very first run of any ffmpeg tool here the WebAssembly core has to be fetched and initialised, which is a one-off download of roughly 31 MB. Then this tool runs its own inspection pass over your file to read the frame rate and the audio codec, and that pass reports no progress at all because it produces no output file.

Can I make a 30 fps clip genuinely smoother by converting it up to 60?

No, and it is worth being blunt about it. Going up fills the extra slots by duplicating frames that already exist, so the file is honestly 60 fps and will satisfy a platform or a project spec that demands one, but the motion carries exactly as much information as it did before. Genuine added smoothness needs interpolation that invents in-between frames, which is far too heavy for a single-threaded browser encoder and tends to smear anything moving fast.

Is 29.97 stored as the literal number 29.97?

No, and that is on purpose. The two NTSC entries map to the exact rationals 30000/1001 and 24000/1001 before they reach ffmpeg, because 29.97 rounded to two decimals is very slightly wrong and that error accumulates against the audio clock over a long recording. It also explains the 0.01 tolerance on the already-at-target check, since ffmpeg's own stream dump prints a 23.976 source as 23.98.

Related tools