Remotion: Making Videos Programmatically with React

Everything moving in that clip is React, it's a Remotion composition rendering live in your browser as you read, not a video file. It's the whole post in one loop, and by the end you'll have seen exactly how it's built.

Most of the time when I find a repo I like, it's because it takes a thing I already know and points it somewhere I didn't expect. Remotion is exactly that. It takes React, the same component model I use every day for web UI, and lets you render actual video files with it. Not a player embedded in a page. Real .mp4 output, frame by frame, from code. The first time that clicked for me, I sat there for a second thinking about how many small video tasks I'd previously written off as "not worth the manual effort."

I'm a working student at BMW and doing CS at LMU, so my time budget for side projects is genuinely tight. The tools that survive in my rotation are the ones that let me automate something repetitive or express an idea without learning a whole new mental model. Remotion fits both, and this note is me thinking out loud about why.

Videos as React components

The core idea is almost suspiciously simple. A video is a function of time. Remotion gives you a hook, useCurrentFrame(), that tells you which frame is currently being rendered, and you return JSX. Everything else is just math on that frame number.

import { useCurrentFrame, interpolate } from "remotion";

export const Title = () => {
  const frame = useCurrentFrame();
  const opacity = interpolate(frame, [0, 30], [0, 1], {
    extrapolateRight: "clamp",
  });
  return <h1 style={{ opacity }}>Hello from frame {frame}</h1>;
};

And here is that exact component running, same interpolate(frame, [0, 30], [0, 1]), live in your browser. Watch the frame number tick and the text fade in:

That's a fade-in. Frames 0 through 30 map to opacity 0 through 1, then it holds. No timeline UI, no keyframe editor, just a pure mapping from time to styles. Once you internalize that, animation stops being a separate discipline and becomes regular programming. You already know how to compose components, pass props, loop over arrays, and pull data from an API. All of that works here, and it all ends up in the rendered video.

The first time this clicked for me was at BMW, where I had been thinking in pipelines and pure functions all day; coming home to my LMU M.Sc. CS side projects, I realized a Remotion fade was the same shape of thinking, just aimed at pixels. Here is that exact component broken down line by line.

export const Title = () => {
  const frame = useCurrentFrame();
  const opacity = interpolate(
    frame, [0, 30], [0, 1],
    { extrapolateRight: "clamp" }
  );
  return <h1 style={{ opacity }}>Hello</h1>;
};

What makes it more than a gimmick is that you get the entire browser rendering stack for free. Anything you can draw on the web, you can put in a frame: CSS layout and transforms, SVG, <canvas>, even WebGL. So your visual vocabulary is enormous and, crucially, familiar. I don't have to learn After Effects' expression language to move a box across the screen; I write the same transform I'd write for a hover state.

The core idea is almost suspiciously simple. Predict it:

Where it actually earns its place

The feature that sells it for me is that video becomes parameterized. Because each composition takes props, you can render the same template hundreds of times with different data. That unlocks a category of work that's miserable to do by hand:

• Personalized video. A "your year in review" clip where the numbers, names, and charts come from each user's data. One template, N renders.
• Automated content from data. Turn a weekly metrics dashboard into a short recap video on a schedule, with the latest figures baked in. The pipeline is just "fetch data, pass as props, render."
• Repeatable marketing assets. Release announcements, changelog clips, social cards that animate. Change the copy in a prop, re-render, done, no designer round-trip for every variant.

The canonical example everyone points to is GitHub Unwrapped, which the Remotion team itself built: it generates a personalized animated recap of your GitHub year. That's the whole pitch in one product, a single video composition driven entirely by per-user data, rendered at scale. It's a convincing demo precisely because doing that any other way would be absurd.

I keep coming back to the data angle because it's where "video as code" beats every GUI tool. A timeline editor is fantastic for a single bespoke piece. It falls apart the moment you need ten thousand variations, or you need the video to stay in sync with a source of truth that changes. Code doesn't care whether it renders once or ten thousand times.

The clearest way I can put the mental model is to set the two workflows side by side and watch what happens when the requirements change:

Drag clip. Set keyframe. Render.
Need a second language? Start over.
Need 50 variants? Hire someone.

That contrast is the whole shift in one frame, and it took me a while to feel it.

The mental shift: from timeline to function

The hardest part of picking up Remotion was not the API. It was unlearning the timeline. In an editor I think in terms of a fixed artifact: this clip, these keyframes, this one finished file. The video is the thing I am making. In Remotion the video is a function, and the file is just one output of calling it. That sounds like a small rewording, but it changes how I plan the work.

Once the video takes props, every decision that used to be baked into the timeline becomes an argument I pass in. Language, name, copy, colors, the data behind a chart: all of it moves out of the artifact and into the call site. So a second language is not a second project, it is the same function with lang: "de". Fifty variants are not fifty afternoons in an editor, they are a loop over fifty rows of data. The first render is genuinely more work than a timeline edit, because I am building the function instead of the result. But every render after that is close to free, and that is exactly why parameterizing the video is what makes variants free.

Not every video task is a fit, though. Run yours through this, the more you tick, the more Remotion beats reaching for an editor:

The browser is the renderer, superpower and catch

There's one design decision underneath all of this that's worth saying out loud: Remotion renders each frame by driving a real browser engine. It opens a headless Chromium, paints your component at a given frame, captures that paint as an image, then advances and repeats. Stitch the frames together and you have a video. That single fact explains both why Remotion feels so good and where it bites.

The good part is the obvious one. Because the renderer is a browser, your entire web visual vocabulary just works. CSS layout and transitions, SVG, the 2D canvas, WebGL, web fonts, your existing component library: none of it is reimplemented or approximated. If it renders in a browser tab, it renders in a Remotion frame. I find that genuinely freeing, because I don't have to learn a parallel "video drawing" API. I already know how to make a div look the way I want.

The catch is the same fact read the other way. Rendering is the cost, and it is not a rounding error. Every frame is a full browser paint, and a one minute clip at 30 frames per second and a high resolution is well over a thousand paints, each one composited and encoded. That adds up fast. A long video, or a high volume batch of personalized renders, is real compute, not something you tack onto a request handler and hope finishes in time.

So you plan for it the way you'd plan for any heavy job. Push renders into CI or a worker rather than blocking a user. Parallelize across machines or frame ranges, since frames are independent and splittable. Cache aggressively: assets, fonts, anything that doesn't change between renders. I haven't run a production render farm myself, so I won't pretend to quote numbers, but the shape of the problem is clear enough from the architecture. Treat rendering as a pipeline concern from day one, and Remotion's browser based approach stays a superpower instead of becoming a surprise.

The whole pipeline is a CLI you can wire into any build, and seeing the commands makes the "video is just a file" claim concrete. Here is the minimal loop I'd run locally before pushing it into CI:

From one render to a hundred variants

The reason I keep circling back to this tool is the economics of scale, and they only make sense once you stop thinking about a single video. Render one clip and Remotion is a curiosity. Render the same composition a hundred times with different props and it turns into a small factory. That shift is where the real argument lives, so here is the rough comparison I keep in my head:

What the slider gestures at, and the numbers above are illustrative rather than measured, is that hand editing scales linearly with human minutes while code scales with cheap CPU minutes. The honest tradeoff is that the first render costs far more in my time than any timeline edit would. I have to build the composition, wire up the props, and test the data path. That up-front cost only pays back when the variant count is high enough to amortize it, which is exactly why the fit checklist earlier matters so much. For one bespoke clip, an editor wins easily. For a hundred near-identical ones driven by data I already have, the factory wins decisively, and the crossover point is lower than I expected before I did the arithmetic.

The category it unlocks is video you would never hand-edit at scale. Switch between the three that sell it for me:

The license caveat, read it before you commit

Here's the part I'd want a friend to tell me up front, so I'll say it plainly: Remotion is not plain MIT/open-everything-goes. It uses a custom license that's free for individuals and small teams, but companies above a certain size need a paid company license. It's source-available rather than fully permissive open source in the way people often assume from a popular GitHub repo.

That's not a knock, I think charging companies to fund the project is a reasonable model, and it's clearly working given how polished the tooling is. But it does mean you should check the terms against your situation before you build something load-bearing on it, especially in a commercial context. "It's on GitHub with 48.7k stars" is not the same as "I can ship this at work without a thought." For a personal side project, you're almost certainly fine; at a company, loop in whoever owns that decision early. I'd rather find out about a license requirement during prototyping than during a launch review.

The specific threshold worth knowing: the company license kicks in once an organization passes a headcount cutoff (it has sat around three employees in the versions I've read), and it's a per-seat developer license, not a one-time fee. That changes the calculus more than people expect. A tool that is free at home can become a recurring line item the moment you bring it into a team of four, and the cost isn't the licence price so much as the procurement conversation it triggers. At a company the size of BMW, "let me just npm install this" is never the real question; the real question is who signs off on a source-available dependency and how long that takes. I've watched perfectly good libraries die in exactly that approval gap, not because they were bad but because nobody budgeted the week it takes to clear them. So I treat the license as an architectural input, not a footnote: if there's any chance the thing ships commercially, I check it before I write a line, the same discipline I apply to every dependency choice in the modern webdev stack for solo founders. The two-minute read of the terms up front is cheaper than the launch-review surprise by a wide margin, and it keeps a genuinely great tool from becoming a political problem.

Where Remotion is the wrong tool

I've spent most of this note arguing for Remotion, so let me argue against it for a minute, because the honest version of "I like this tool" includes the cases where I wouldn't touch it. The first one is the obvious one: a hand-crafted cinematic edit. If the job is a single hero piece where the cut timing, the music sync, and the feel of each transition are the whole point, a timeline editor is simply the right instrument. Premiere and After Effects exist because a human eye nudging a clip by two frames is doing real work that a frame-number function does not capture well. I'd never write that in React, and pretending otherwise would be ideology, not engineering.

The second is render cost at scale. I covered the browser-paint pricing earlier, but it's worth saying as a reason not to reach for the tool: if you only ever need one video, the render overhead and the up-front cost of building a composition buys you nothing. You pay the engineering tax without ever collecting the variant dividend that justifies it.

The third is the learning curve, and this one is conditional on you. The whole reason Remotion feels cheap to me is that I already live in React and TypeScript. If you don't, the framework is not a gentle on-ramp to video; you'd be learning a component model, a hooks mental model, and a rendering pipeline all at once just to make a title card move. The same effort spent on a SaaS template tool would have you shipping the same afternoon. I'd give the same caution to anyone weighing whether the modern webdev stack for solo founders is worth adopting wholesale: the leverage is real, but only once the stack is already in your head.

And sometimes a SaaS template or a timeline editor is just faster, full stop. A one-off social clip from a drag-and-drop tool, a quick trim of a screen recording, a birthday video for a friend: reaching for code there is the engineer's version of over-tooling. Remotion earns its place on repetition, data, and automation. Absent those, the boring tool wins, and I try to be honest with myself about which situation I'm actually in before I open an editor or a code file.

How I'd actually use it

Realistically, my first use wouldn't be anything ambitious. I'd start by turning a static thing I already make into a short animated version. I write a fair amount, when I publish something on my /blog, a 10-second animated title card or a small "what changed" recap clip for social would be a nice touch, and it's the kind of asset I'd never hand-animate repeatedly. Build the template once, feed it the post title and date as props, re-render per post. That's the sweet spot: low stakes, high repetition, data I already have.

The next step up would be something portfolio-flavored. I like the idea of a generated clip that summarizes a project, pull a few stats, animate them in, export. It fits the same instinct behind the work I describe in my /#projects section: take something I'd otherwise do manually and make it produce itself. And because the output is just a file, it slots into any normal pipeline, commit the composition, render in CI, drop the result wherever it needs to go.

What I appreciate most is that there's no new runtime to reason about. It's React, TypeScript, and the browser's rendering model, three things I already trust. The learning curve is mostly "unlearn the assumption that video needs a separate tool," not "memorize a new API surface." For someone who values shipping over fiddling, that's the right kind of tradeoff.

If you're not sure whether your own situation actually calls for Remotion, the decision usually comes down to two questions: how many videos you need, and whether you already live in React. Walk your case through this and it'll point you somewhere honest rather than just selling you the tool:

I'm not going to pretend I've shipped a production video pipeline with it yet, I haven't, and I won't invent metrics to sound impressive. This is a note about a tool I find genuinely clever and expect to use, written while the idea is fresh. If you live in React and have ever thought "I wish I could generate this video instead of editing it," Remotion is worth an evening of your time. Start small, read the license, and see if it changes how you think about video the way it changed how I do. If you want more about how I pick tools and projects in general, that thread runs through a lot of what's on my /cv.

So I built the three clips I described

Rather than just describe these ideas, I built them. The three clips below are exactly the use cases from the section above, an animated blog title card, a project recap, and a brand intro, written as Remotion compositions. They aren't pre-rendered videos: each one is the actual composition running live in your browser as React, the same code that would render to an .mp4. The title card is even fed this post's own title, date, and tags as props.

That's the part I find quietly convincing. There's no asset pipeline behind these, change a prop, and the clip re-renders. Build the template once, point it at different data, and you have as many videos as you have rows.

And because each clip is just a composition, stitching them into one longer reel is a few lines of @remotion/transitions. Here's that same reel again, it starts playing the moment it scrolls into view:

FAQ

What is Remotion?

Remotion is an open-source framework for making videos programmatically with React. You compose video as React components, drive it with props and data, and render real video files (like MP4) from code instead of editing them by hand in a timeline editor.

Is Remotion free to use?

Remotion is free for individuals and small teams, but it is source-available rather than fully permissive open source. Companies above a certain size need a paid company license, so check the terms against your situation before using it commercially.

What can you build with Remotion?

It's best for data-driven, repetitive video: personalized clips, automated social cards, "year in review" style recaps, animated title cards, and any video where you'd otherwise repeat the same manual editing for different inputs.

Do you need to know video editing to use Remotion?

No. If you know React, CSS, and basic animation timing, you can build with Remotion. The model is a function of a frame number, so it's closer to web development than to traditional video editing.

Whatever you reach for next, the pull is the same for me: treat video as code you can render on demand. If that clicks for you, let us talk.