How a Photo Slideshow Becomes a Video

After reading this you will understand how still images turn into a timed video with transitions, why the render takes as long as the show itself, and how to pick a duration, frame rate and resolution that produce a smooth, sharable file.

What a slideshow video actually is

A slideshow feels like a stack of photos with fades between them. To a video encoder it is something more mechanical: a sequence of identical-sized frames, drawn one after another at a fixed rate, then compressed. If you show 8 photos for 4 seconds each at 30 frames per second, the output is not 8 pictures. It is 960 frames.

The tool builds those frames on an HTML canvas. Each frame is a full-resolution image, for example 1920 × 1080 pixels at 1080p. During a transition, two photos are blended into the same frame. During a still hold, one photo fills the frame, optionally drifting or zooming a little. The browser's video encoder reads these frames in order and writes a compressed WebM file on your device. Nothing leaves the machine.

The optional MP4 conversion runs FFmpeg compiled to WebAssembly, downloaded from a CDN the first time you use it. The slideshow itself renders to WebM using the browser's own encoder, with no download required.

When a rendered video is the right choice

Render a video when the destination is a video player: a phone gallery, a social feed, a TV, a presentation that autoplays. A single MP4 or WebM plays anywhere and keeps your photo order, timing and music exactly as designed. That is its advantage over a folder of images.

Skip the render when you only need to flip through photos yourself, or when you want viewers to zoom into full detail. Video compression is lossy. A 1080p frame throws away fine texture that the original JPEG kept, and text in a screenshot can turn fuzzy. For archival or print, keep the originals. For sharing a timed, musical sequence, a video is the correct format.

The timing math

Three numbers set the size and length of the job: the number of photos, the seconds per photo, and the frame rate. The total number of frames the encoder must produce is their product.

N_{\text{frames}} = n_{\text{photos}} \times t_{\text{sec}} \times f_{\text{fps}}

Here n_{\text{photos}} is how many images you added, t_{\text{sec}} is the display time for each one in seconds, and f_{\text{fps}} is the frame rate. The total duration in seconds is simply n_{\text{photos}} \times t_{\text{sec}}, independent of frame rate. Frame rate changes smoothness and file size, not length.

Transitions do not add time in this model. A 1-second cross-fade between two photos overlaps their hold periods: it eats the last half second of one photo and the first half second of the next, rather than extending the show. If you want each photo readable for a full 4 seconds, add the transition length on top by setting a longer per-photo time.

A worked example with the defaults

Six photos, cross-fade, 1080p

Take the demo defaults: 6 photos, 5 seconds each, a 1-second cross-fade, 30 fps, output at 1080p landscape (1920 × 1080).

Total duration: 6 \times 5 = 30 seconds.
Total frames: 6 \times 5 \times 30 = 900 frames.
Pixels drawn per frame: 1920 \times 1080 = 2{,}073{,}600 pixels, about 2.07 megapixels.
Pixels drawn for the whole show: 900 \times 2{,}073{,}600 \approx 1.866 \times 10^{9}, roughly 1.87 billion pixel writes before compression.
Cross-fade frames: a 1-second fade at 30 fps is 30 blended frames. With 5 internal transitions (between 6 photos), that is 5 \times 30 = 150 frames where two images are composited instead of one.

Because rendering happens in real time, this 30-second show takes about 30 seconds to record. Keep the tab in the foreground: most browsers throttle background tabs, which drops frames and corrupts timing.

Resolution, frame rate and file size

File size scales with three things: pixels per frame, frames per second, and how hard the scene is to compress. Still holds compress well because consecutive frames are almost identical, so the encoder stores mostly "no change." Transitions and Ken Burns motion change every pixel slightly each frame, so they cost more bits.

The table shows the raw pixel throughput for common settings before compression. Compression typically shrinks this by a factor of 50 to 200 depending on motion, so treat these as relative workloads, not final file sizes.

Pixels processed per second at each setting
Resolution	Pixels/frame	fps	Pixels/second
720p (1280×720)	921,600	30	27.65 million
1080p (1920×1080)	2,073,600	30	62.21 million
720p	921,600	60	55.30 million
1080p	2,073,600	60	124.4 million

Going from 720p to 1080p at the same frame rate multiplies the workload by 2.25 (that is 2073600 / 921600). Doubling frame rate doubles it again. For a slideshow with slow motion, 30 fps is plenty; 24 or 30 fps looks natural and keeps files small. Reserve 60 fps for fast pans.

1080p at 60 fps moves about 4.5 times more pixels per second than 720p at 30 fps.

Transitions and the Ken Burns effect

A transition is a rule for combining two images across a set of frames. Understanding the blend explains why some look smooth and others look abrupt.

Hard cut: No blend. One frame shows photo A, the next shows photo B. Zero transition frames. The sharpest, cheapest change.
Cross-fade: Over the transition, the output pixel is a weighted mix: \text{out} = (1-\alpha)\,A + \alpha\,B, where \alpha runs from 0 to 1 across the transition frames. At the midpoint both photos show at half strength.
Slide: Photo B enters from one edge while A exits the other. No opacity change; the boundary moves across the frame.
Zoom (Ken Burns): A slow scale and pan applied during the still hold, not the transition. A photo might start at 100% and drift to 108% over 5 seconds, giving stills a sense of motion.

For a 1-second cross-fade at 30 fps, \alpha increases by about 1/30 \approx 0.0333 per frame. On frame 15 of 30, \alpha \approx 0.5, so you see equal parts of both photos. The chart below traces one photo's weight through a cross-fade.

A straight ramp from 0 to 1 across 30 frames; the marked frame 15 sits near the 0.5 midpoint.

Audio: fitting music to length

An audio track rarely matches the slideshow length exactly. The tool handles the mismatch simply: if the music is longer than the show, it trims the tail; if you want a clean ending, it fades out over the last second or two rather than cutting mid-note. If the music is shorter, the show still ends at its set duration and the audio ends earlier.

For the 30-second demo, a 3-minute song plays only its first 30 seconds. If that intro is quiet and the payoff comes at 45 seconds, trim the song beforehand so the strong part lands inside the window. If you need a steady rhythmic bed instead of a song, generate a click with the Metronome, or build a short loop in the Synth & Music Theory Studio. For narration over the slides, record a voice track from the Text to Speech Playground.

Match the music's beat count to your photo count. At 120 beats per minute, one bar of 4 beats lasts 2 seconds. Setting each photo to 2, 4 or 8 seconds makes changes land on the downbeat, which reads as deliberate rather than accidental.

Common mistakes

The errors that ruin a render are almost always about timing, tabs and expectations.

Backgrounding the tab. Rendering is real time. If you switch tabs, the browser throttles the timer and the encoder drops frames. A 30-second show will finish with stutters or a wrong length. Leave the tab visible until it finishes.
Per-photo time too short. Below about 2 seconds, viewers cannot absorb a busy photo, and a 1-second transition then covers most of the hold. Keep detailed images on screen 4 to 6 seconds.
Mixed aspect ratios. A portrait phone photo placed in a 1080p landscape frame either shows bars on the sides or gets cropped. Decide the output shape first (landscape, portrait or square), then pick photos that suit it.
Expecting print quality. Video compression discards fine detail. Do not use a slideshow render as a substitute for the original files.
Over-zooming. A Ken Burns move past roughly 110% starts to soften the image, because the source has fewer pixels than the zoomed frame needs. Keep drifts subtle.

Frequently asked questions

Why does a 30-second slideshow take 30 seconds to render?

The browser's video encoder records frames as they are drawn, in real time, the same way a screen recorder captures a live playback. There is no faster batch mode available in the browser, so recording time roughly equals playback length.

Are my photos uploaded anywhere?

No. Frames are drawn on a canvas and encoded on your device. The files never leave your browser. The only network request is the optional FFmpeg download for MP4 conversion, and that downloads code, not your images.

WebM or MP4, which should I pick?

WebM renders instantly with the built-in encoder and plays in modern browsers and most platforms. Choose MP4 when a specific target (an older phone, some social uploaders, certain editors) rejects WebM. MP4 costs an extra conversion pass and a one-time FFmpeg download.

How do I make transitions land on the music?

Set the per-photo time to a whole number of beats. Find the tempo, divide 60 by it for seconds per beat, then multiply by the beats you want per photo. At 100 BPM, one beat is 0.6 seconds, so 4 beats is 2.4 seconds per photo.

Can I reorder photos after adding them?

Yes, by drag and drop before rendering. Order changes are free; only the final render costs real time. Preview the sequence, adjust the order, then render once you are satisfied.

Try it yourself in the tool