What you can
ask for.

A video is a fast sequence of still pictures. Each of these pictures is called a frame. When the pictures change fast enough, the eye stops seeing separate images and sees continuous motion. How fast? That's the fps, short for frames per second. Cinema uses 24, the web usually 30, and motion graphics of interfaces 60. Why isn't 24 enough? Because a camera smears fast movement (this is called motion blur), and the smear fills the gap between pictures. A picture drawn in code is perfectly sharp, so at 24 or 30 we see it jump. At 60 the jumps are small enough, and phone screens refresh at least 60 times per second too.

The price of 60: more pictures to compute. A 30-second video at 60fps is 30 × 60 = 1,800 pictures. Every picture is made of pixels, tiny squares of a single color, and the resolution says how many there are: 1920×1080 means 1,920 pixels across and 1,080 down. The ratio between width and height is the aspect ratio: 16:9 is a landscape screen (YouTube, presentations), and 9:16 is a portrait screen (Reels, TikTok, Shorts).

And here's the insight the whole catalog stands on: to make a video, all we need is a way to draw picture number N. If we can draw any frame on demand, we can ask for frame 0, then 1, then 2, all the way to 1,799, and stitch them together. That's the whole secret of "video that is code".

Where do the pictures come from? From a web page. The browser (Chrome, for example) is a free and remarkably powerful drawing engine: it can draw text in any language, including right-to-left languages like Hebrew and Arabic, in any font, plus shapes, images, video and even 3D. And Claude writes web page code fluently, because it's the most common kind of code on the internet.

A web page is built from three languages, and each one is responsible for a different layer. The demo below has one button from the Ketzev film. Toggle each layer off and on and see what it contributes:

• HTML says what's there on screen: "there's a button, and it says Start workout". Each such item, a button or a heading or an image, is called an element.
• CSS says how it looks: orange, fully rounded, in the Anton font. Without CSS we get the browser's plain gray default button.
• JavaScript (JS for short) says what happens. In our case: how the button changes over time. Without JS the button freezes.

The JS lines in the demo use seek and spring. No need to understand them yet; they're explained in steps 0.7 and 0.8.

So how does a page like this become a video file? With two free tools. Playwright is a Microsoft tool that opens an invisible browser and drives it from code: "open the page, set the time to 0.5 seconds, capture", and again and again, 1,800 times. ffmpeg is a veteran program that stitches the pictures, together with the music, into a single MP4 file. It also compresses: 1,800 full pictures weigh several gigabytes, while an MP4 file mostly stores what changed from one picture to the next and gives up tiny differences, which is why it's hundreds of times smaller. The price: fine details, like a slow color gradient, can suffer.

A library is code someone else wrote, tested and shared, so we don't have to write it ourselves. Drawing a chart correctly, with axes, ticks, labels and spacing, is weeks of work. A library like Recharts does it in ten lines. npm is the world's largest registry of JavaScript libraries, and it's free: the command npm install recharts downloads the library into the project. A library packaged for npm is called a package, and it has a version number like 3.2.1. The first number goes up when the new version is no longer compatible with code written for the old one, the middle one when a capability is added without breaking anything, and the last one when a bug is fixed. That's why we specify a version: if Claude knows version 2 and the project installs version 3, some of the code might not work. (A command like this is typed in the terminal, a text window where we give the computer instructions. In practice, Claude Code types it for us.)

Why does this matter in a prompt? Because Claude knows the popular libraries well, and the right way to use them. When we write "a Recharts area chart", it knows exactly what to build. When we write just "a chart", it may improvise a homemade version that looks average. An exact name turns a vague request into a clear target.

A license is the legal permission to use the code. Every element in the catalog is marked with its license, and three types keep coming up:

• MIT and ISC: almost anything goes, including commercial work for a client. The only condition is keeping the copyright notice in the code.
• Apache 2.0: similar, and adds protection against patent claims.
• CC0: public domain. No conditions at all.

A component is a building block we can use again and again, with settings. Like a Lego brick that comes in several colors and sizes: the same button can be orange or transparent, large or small. These settings are called props. React is a library from Meta for building interfaces out of components. Instead of telling the browser "move this, color that", we describe to it what the screen should look like given the data. Every time the description changes, React compares it with the previous one and changes only what actually changed on the page.

And that's exactly what video needs. We compute the frame's data from the time ("at second 3.6, progress is 72%"), hand it to React, and it draws exactly that frame. The same input always gives the same picture. A function is a recipe in code: we put a value in (the input) and it returns a result (the output), for example time goes in and a progress percentage comes out. A function that has no hidden memory, and whose result depends only on its input, is called a pure function:

function Frame({ t }) {                       // t = the time in seconds
  const progress = Math.min(100, t * 20);     // 0% at t=0, 100% at t=5
  return <Progress value={progress} />;       // a ready-made progress-bar component
}

The progress is t times 20, but never more than 100 (Math.min picks the smaller of the two). The number goes to a ready-made component that draws a progress bar (Progress, which we'll meet in chapter 02).

There are two ways to store an image. Vector stores a description: "a circle, the center is here, the radius is this much, the color is orange". When we enlarge it, the computer redraws it from the description, so the edges stay sharp at any size. The web's vector format is called SVG. Raster stores a grid of pixels (PNG, JPG): when we enlarge it, each pixel becomes a big square, or smears if smoothing is turned on.

In motion this is critical, because the camera zooms: a 3× push-in on a logo is a 3× enlargement. In the demo, both sides show exactly the same icon. Turn up the zoom and see what happens to each one:

The rule: logos, icons, shapes and text are always vector. Photos are raster by nature, and that's fine, as long as their resolution is higher than the size they'll appear at after the zoom.

• DOM (short for Document Object Model) is the usual way. The browser keeps every element as an object in memory, with all its styles, works out what goes where, and draws. Excellent for text and interfaces, and slow when there are thousands of elements, because each one has to be stored and computed.
• Canvas is a blank drawing board of pixels. We give it commands ("draw a circle here") every frame, and it doesn't remember what was drawn. Very fast for thousands of shapes, but everything is on us: no automatic layout, no line wrapping.
• WebGL is a way to draw through the graphics card (GPU). A regular processor has a few powerful cores that each work through tasks one after another; a graphics card has thousands of small cores that compute thousands of points in parallel. That's why 3D and tens of thousands of particles go through it. The three.js library makes it comfortable to use.

In the demo, the same points are drawn in all three ways, and the time is measured right now on your device. Slide it to 30,000 and press "Measure now":

Why is the number 16.7 marked? At 60fps each frame gets 1,000 ÷ 60 = 16.7 milliseconds. Anything that takes longer stutters in live playback. But here's the important nuance: when we produce a video file, there is no budget. Playwright waits as long as each frame needs, so a heavy scene that stutters in the preview (the live playback in the browser while we work, before we produce a file) will come out perfectly smooth in the video. On one condition, which is the subject of the next step: the page draws each frame from a time number it's given, not from the clock. The budget matters for the preview and for working speed, not for the result.

Most libraries animate by the wall clock: "move this over one and a half seconds of real time". In a browser that's perfect. But while capturing a video, each frame takes 100 to 500 milliseconds to capture, because for every capture the browser has to finish drawing, turn about 2 million pixels into an image file and hand it to the program doing the capturing. That's 6 to 30 times longer than the 16.7 milliseconds of live playback. Meanwhile, the library's animation keeps running in real time, and within a few frames it's already over. The video jumps.

The fix, applied in every demo on this page: turn off the library's animation and compute everything from t. Frame number i gets t = i ÷ 60, and draws whatever should be on screen at that moment. That way frame 37 is always the same picture, no matter how long it took to capture. The function that draws the picture for moment t is called seek(t). The demo captures 12 frames with both methods, with random capture times, just like in real life:

In the top row, the dot reaches the end after just a frame or two, and the rest are wasted. In the bottom row, each frame shows a small, equal step. Every prompt on this page includes the sentence that enforces this. Most libraries have a way to turn off their built-in animation: in the Recharts chart library (chapter 01) it's a single setting, isAnimationActive={false}. The interface components we'll meet in chapter 02 have no such switch, so we delete the instructions in their code that make the browser animate on its own.

Nothing in the world moves at a constant speed: a ball speeds up as it falls, a door slows down before it closes. That's why motion at a constant speed (linear motion) looks mechanical. Easing is a curve that converts "how much of the time has passed" (from 0 to 1) into "how much of the way we've covered". It comes in three common shapes, and we'll see their names in the prompts: ease-in starts slow and speeds up, ease-out slows down at the end, and ease-in-out does both.

A spring is a curve that overshoots the target a little and comes back, like a door on a spring hinge. It has two settings: stiffness (how fast it gets there) and damping (how quickly the bounces die down: higher damping, fewer bounces). In the catalog we compute the spring with a closed-form formula: we plug in t and immediately get the position, without computing all the frames before it. That's why it obeys the t rule:

const spring = (t, w = 12, z = 0.8) => {    // w = frequency (higher = faster), z = damping, must stay below 1
  if (t <= 0) return 0;
  const wd = w * Math.sqrt(1 - z * z);
  return 1 - Math.exp(-z * w * t) * (Math.cos(wd * t) + (z * w / wd) * Math.sin(wd * t));
};
// spring(0.1) = 0.38, spring(0.2) = 0.79, spring(0.4) = 1.013 (just past the target), spring(0.6) = 1.005, then 1

How to read it: in the code, w is the stiffness (a higher number means a faster spring; technically it's the spring's frequency) and z is the damping. Math.exp(…) is the brake, a number that starts at 1 and shrinks over time, which is why the oscillation fades. cos and sin rise and fall in a smooth, repeating wave between -1 and 1, and they are the oscillation itself. (If a point's horizontal position is cos of t and its vertical position is sin of t, the point moves in a circle. That's how the circles move in several of the effects later on.) z must stay below 1, because at 1 the formula divides by zero; 0.99 means almost no bounce. When the prompts say "closed-form springs", this is what they mean. An interactive lab for playing with stiffness and damping is in the springs chapter on the method page.

Every prompt here is built on the same skeleton, developed by the creator zero (@twoclipping) for his launch films. A language model that doesn't get precise instructions gives us the average of what it has seen, and in motion the average is a "template": dark background, glow, particles and a fade (a transition where one picture slowly dissolves and the next one appears beneath it). The six blocks erase the average:

• <inputs>: what Claude needs to ask us for before it starts (data, logo, music), and what to do if we don't provide it.
• <direction>: the taste. Format, colors as exact codes, fonts by name, and a list of what's forbidden. An exact color is written like this: #FF8F3A. That's three pairs of characters: how much red, how much green and how much blue, from 00 (none) to FF (the most, 255). Lots of red, some green and a little blue make orange, and that way Claude gets exactly the shade we mean.
• <structure>: what happens when, in beats of the music. A beat is a single pulse of the song, and tempo is measured in beats per minute (BPM). At 120 BPM: 60 seconds divided by 120 = half a second per beat. 120 is common in popular music, and the numbers come out round: one beat = 0.5 seconds = 30 frames at 60fps.
• <build>: how to build it. This is where the t rule and the technical instructions for each library go.
• <gotchas>: known bugs, listed up front, so Claude avoids them on the first pass.
• <start>: a cheap approval gate. First a beat map (a list of what happens on each beat) and four stills (single pictures from the film), and only after we approve, the full film. It's cheap because four pictures are created in seconds, while rendering, producing all the frames into the final file, takes many minutes.

Library names, function names and technical terms are English anyway, so these prompts work as-is in any tool. The on-screen text inside them is whatever language the film uses: here it's English, and for a film in another language we just swap those strings. A full breakdown of each block, and why it works on a language model, is in the anatomy chapter on the method page.

Kinetic typography is text whose motion is part of the message: a word that lands hard feels important, a word that gets typed out feels like a conversation. In a launch video most of the screen is text, which makes this maybe the most important element in the catalog. The demo below runs four techniques back to back, two and a half seconds each.

In the previous chapter three.js did the work for us. Now we go one layer down, to two questions: who actually draws, and in which language we talk to it.

• Graphics card (GPU): a processor made of thousands of small cores that do the same operation on lots of data at once. The regular processor (CPU) is a few expert chefs; the graphics card is a thousand cooks who each chop one cucumber. Drawing an image is exactly that kind of work: millions of pixels, and the same calculation for each one.
• WebGL: the browser's long-standing way to talk to the graphics card, since 2011 (and version 2 since 2017). It works in almost every browser and device, and three.js uses it by default.
• WebGPU: the new way. Faster when there are many objects, and it can also do general computing (compute): using the graphics card not only for drawing but for any calculation that repeats, like a simulation of hundreds of thousands of particles. According to Google (November 2025) it is available in Chrome and Edge (on Windows, macOS, ChromeOS and Android), in Safari 26, and in Firefox on Windows and on Macs with ARM chips. On Linux it is still on its way, and that matters to us, because render machines usually run Linux.
• Shader: a small program that runs on the graphics card. A fragment shader runs once for every pixel in every frame and returns a colour. A vertex shader runs once for every point of a shape and decides where it appears on screen. In WebGL shaders are written in GLSL, in WebGPU in WGSL.
• TSL (Three Shading Language): three.js's shader language. We write it as ordinary JavaScript, and it turns into WGSL or GLSL by itself, depending on what the browser supports.

Why does this matter for a film? Because a shader is exactly a function of time: colour = f(pixel, t). It is the same idea as seek(t), except the graphics card runs it on a million pixels at once. A sunset, a sea, marble and film grain are a few lines of code, with no image file at all.

How to choose an engine, in four lines

1. Interface, buttons and text: HTML and CSS. The browser already draws them very well.
2. Illustrations, charts and 2D motion: Canvas 2D, a drawing surface we paint on with commands.
3. 3D, materials and shaders: three.js with WebGLRenderer. The safe choice for rendering.
4. Hundreds of thousands of particles or a simulation: three.js with WebGPURenderer, which falls back to WebGL 2 by itself when there is no WebGPU.

All license and pricing details were checked on October 17, 2026. Prices change, so before any commercial work it's worth checking again through the link in the sources.

How to choose, in four questions

1. One film or a hundred? One: HTML and seek(t). A hundred from the same template: Remotion or HyperFrames.
2. Is there a ready-made animation from a designer? Lottie fits into any of these approaches.
3. Does it live inside an app and react to the user? Rive. At that point it's no longer a video question.
4. Need a custom 3D model? Blender or Spline, export to GLTF, and bring it into three.js.