Frame rate is the most visible property of a video after resolution and the least understood. People know that 60 looks smoother than 30 and that cinema is 24, but the reasons behind those numbers, and what actually happens when you convert between them, involve a mix of physiology, broadcast history and arithmetic that is genuinely worth knowing before you change the setting.
What the numbers mean, and why they are those numbers
A video is a sequence of still images shown quickly enough that a viewer perceives motion. The rate is how many of those images occupy one second, and the common values are not arbitrary.
Twenty-four is the film standard, settled in the late 1920s as roughly the slowest rate that produced acceptable motion while keeping the cost of film stock down. It stuck, and generations of viewers have learned to read its particular motion character as looking cinematic. That is learned association rather than an inherent property, but it is real: footage at 24 reads as film to most audiences.
Twenty-five and thirty come from electricity. Early television synchronised to the mains frequency to avoid interference, so regions on 50 Hz power standardised on 25 frames per second and regions on 60 Hz on 30. That split still shapes broadcast content today, and it is why European and American formats disagree on a number that has nothing to do with either continent’s aesthetics.
Fifty and sixty are the doubled versions, used where motion clarity matters more than tradition: sport, video games, screen recordings and anything with fast panning.
The fractional rates, and why they persist
Open a video file’s properties and you will regularly see 23.976, 29.97 or 59.94 instead of the round number. That is not a measurement error or a rounding artifact.
When colour was added to the existing black-and-white NTSC television system, the colour information had to be carried alongside the existing picture and sound without interfering with either. The solution involved slowing the frame rate by a factor of exactly 1000/1001, which is where 30 becomes 29.97 and 24 becomes 23.976. The change was small enough to be invisible and sufficient to move the signals apart.
Decades later that fraction is still in every part of the pipeline, and it matters for a practical reason: those rates must be handled as exact rational numbers rather than as the decimal approximations people write down. Our own frame rate converter passes an exact rational to the encoder rather than a rounded decimal for precisely this reason. A drift of one part in a thousand sounds negligible until you consider an hour-long file, where it accumulates into several seconds of desynchronisation between picture and sound.
It also affects diagnosis, because tools that report frame rate typically round for display. A file shown as 23.98 fps is almost certainly 23.976, and a converter comparing a rounded display value against a target can conclude a file needs converting when it does not.
What conversion actually does to the frames
This is the part that determines whether a conversion is worth doing, and it is simpler and blunter than most people assume.
Converting frame rate does not synthesise new moments in time. It selects from the moments that exist. Going from 60 to 30 drops every second frame. Going from 30 to 60 duplicates each frame once. Going between rates that do not divide evenly produces an irregular pattern of drops and duplicates, which is where the trouble starts.
Downward conversion is generally safe. Discarding frames loses motion detail, but what remains is genuine, evenly spaced and looks like normal footage at the lower rate. It is a real reduction in file size and a common step before uploading.
Upward conversion buys nothing. Duplicating a frame does not add information; the video still contains the same number of distinct moments, so it looks identical while occupying more space. The only reason to do it is a technical requirement from a platform or an editing timeline that demands a specific rate.
The genuinely awkward case is conversion between rates with an awkward ratio, most famously 30 to 24. Since the ratio is not a whole number, some frames are kept and others dropped in a repeating but uneven pattern, so motion advances in slightly unequal steps. On a static shot nobody notices. On a slow, steady camera pan it produces a visible judder that is difficult to unsee once you have learned to spot it. No converter avoids this; it is a property of resampling a timeline, and the broadcast industry’s traditional answer, pulldown, is a scheme for distributing the unevenness rather than eliminating it.
There is one deliberate refusal worth mentioning: our converter stops rather than proceeding if the source is already at the target rate. Re-encoding a file to the rate it already has costs a generation of quality and achieves nothing, so the honest response is to say so rather than to produce a slightly worse copy of the input.
Frame rate is not speed
These two get conflated constantly, and the distinction is worth stating plainly.
Changing the frame rate keeps the timeline and changes how densely it is sampled. A ten second clip stays ten seconds. Changing the speed alters the timeline itself: the same frames are played over a different duration, so a ten second clip becomes five or twenty.
If what you want is slow motion or a timelapse, changing the video speed is the operation, not a frame rate conversion. And there is a real interaction between them: slowing footage shot at 30 fps by half produces an effective 15 distinct images per second, which looks choppy, whereas footage shot at 60 and slowed by half still has 30 distinct images per second and looks smooth. This is the entire reason people shoot at high frame rates for slow motion. The rate you need is decided at capture, and no conversion afterwards recovers it.
Where frame rate meets file size
Frame rate and compression pull against each other in a way that catches people out when uploading.
At a fixed bitrate, the data budget is shared among the frames in each second. Doubling the frame rate halves what each frame gets. So a 60 fps file squeezed to the same size as a 30 fps version of the same footage will show more artifacts per frame, not fewer. If a platform or an attachment limit is forcing a size, reducing frame rate is often a better trade than reducing resolution, especially for talking-head content where motion is minimal. That interaction is worth having in mind before reaching for video compression, since the frame rate you arrive with determines how much work the compressor has to do.
The extreme case is animated GIF, where frame rate is the dominant cost. A GIF stores frames with a palette of at most 256 colours and no motion compensation between them, so every frame is close to a full picture and the file grows roughly linearly with the number of frames. This is why converting video to GIF defaults to a much lower rate than the source: something around 15 frames per second reads as acceptably smooth for a short loop while keeping the file within the size a chat application or a forum will accept. Dropping to 10 is a legitimate further economy for a reaction clip. Keeping 30 produces a file several times larger for a format nobody watches closely.
Choosing a rate deliberately
Match the source when you can, because every conversion is a re-encode and re-encodes cost quality. Convert downward when you need the file smaller and the motion is not the point. Convert upward only when something technical demands it. Decide slow motion at capture, not afterwards. And when a number in a file’s properties looks odd, check whether it is one of the fractional broadcast rates before assuming something is wrong.