Client-Side Rendering vs Server-Side Rendering, Explained Simply
A simple explanation of what happens when you render a video, why Remotion server-side rendering costs money, what client-side rendering changes, and why the browser version has limitations.
Sam
Creator of RVE
You edit a video in the browser. You click Render. Why does anything need a server?
That is the part that confuses people.
The editor can preview your video because the browser is good at showing web pages. Exporting an MP4 is different: every frame has to be rendered, audio has to be mixed, and the result has to be encoded into a real video file.
There are two ways to do that:
Key takeaways
- Server-side rendering sends the job to a backend, worker, or Remotion Lambda function. The finished video comes back as a download.
- Client-side rendering tries to render and encode the video directly in the user's browser.
- Client-side rendering can remove server cost for simple exports, but Remotion's browser renderer is still experimental and has compatibility limits.
Server-Side Rendering
This is the traditional Remotion rendering flow.
When you click render, the browser sends the job to another machine. That machine loads the Remotion composition, renders the frames, encodes the video, stores the file, and sends back a download URL.
This is the reliable path for production workloads. It is also why Remotion Lambda exists: you can scale rendering across cloud workers instead of depending on one user's laptop.
The tradeoff is obvious: servers cost money and need setup.
Client-Side Rendering
Client-side rendering moves that work into the browser.
No Lambda job. No render queue. No backend compute bill for that export.
The browser loads the composition, steps through the frames, draws them locally, captures supported media, and encodes the result using browser media APIs.
That is why it feels exciting for RVE. A browser-based editor can finally offer a real local export path for the right kinds of videos.
Why It Has Limits
Browsers do not expose a perfect "capture this whole webpage as a video" API.
So Remotion's client-side renderer has to reconstruct the output. It inspects the DOM, measures layout, reads supported styles, draws to a canvas, and then encodes the video.
That is clever, but it means only supported browser APIs, elements, and CSS properties can be used. Remotion's own docs call client-side rendering experimental and list the current limits in detail: Remotion client-side rendering limitations.
Here is the practical version.
Client-side render compatibility
A simplified snapshot of the Remotion browser renderer limits that matter most when building an editor.
| Feature | Client-side render | Server-side render | Why it matters |
|---|---|---|---|
| Layout and sizing | Mostly supported | More forgiving | Position, size, flex layout, transforms, opacity, borders, and radius are covered because Remotion can measure elements in the DOM. |
| Backgrounds | Partial | More complete | Background colors and linear gradients are supported. Many other background-image and background-* combinations are not. |
| Text | Partial | More complete | Common font, size, weight, color, line-height, spacing, and shadow styles are supported. Some text features like writing-mode and text-decoration are not. |
| Layering | Limited | More complete | z-index is not supported. Draw order comes from element order, so put later elements on top. |
| Filters and effects | Partial | More complete | Many filter functions work in Chrome and Firefox, but filters are not supported in Safari/WebKit. backdrop-filter and mix-blend-mode are not supported. |
| Remotion media components | Specific set | Broader support | Use supported components such as @remotion/media Video and Audio. OffthreadVideo, Html5Video, Html5Audio, and AnimatedEmoji are not supported in this mode. |
| Browser support | Modern browsers | Server controlled | Client-side rendering depends on APIs like WebCodecs, so browser support is narrower than normal video playback. |
| Scale | One device | Scales better | Client-side rendering runs on the user's device. Server-side rendering can spread jobs across cloud workers. |
Option A
Server-side rendering
- The job is sent to a server, worker, or Lambda function.
- More mature and better for large-scale production rendering.
- Costs money and requires backend infrastructure.
Option B
Client-side rendering
- The job runs inside the user's browser.
- Can be faster and cheaper for simple local exports.
- Experimental and limited by browser APIs, CSS support, and device performance.
Which One Should You Use?
Use server-side rendering when you care most about reliability, scale, and production consistency.
Use client-side rendering when you want a lightweight browser export, lower infrastructure cost, and your composition fits inside the current limitations.
Server-side rendering is still the stronger default for high-volume production rendering. Client-side rendering is very promising for demos, prototypes, simple exports, and product flows where avoiding backend rendering is a big win.
What This Means In RVE
React Video Editor now supports client-side rendering, but it does not force one rendering strategy on every product.
You can:
- use RVE's client-side rendering path
- pass your own custom client-side render implementation
- use server-side rendering instead
- wire up your own render provider behind the scenes
That choice is intentional. Some teams want the demo-style "click render and download locally" experience. Others want a production Lambda setup. Others already have their own rendering infrastructure.
Why The Demo Shows A Warning
If you click render on the RVE demo site, the warning is there because the local browser export path is still constrained by Remotion's client-side renderer.
The warning is not saying the feature is bad. It is saying: do not expect local browser export to behave exactly like a production server render for every composition.
That expectation matters if your video uses unsupported CSS, unsupported Remotion components, Safari-only behavior, or a device that struggles with encoding.
Why client-side rendering is exciting
- You can render without paying for a server render on every export.
- The workflow can feel faster and more direct for simple videos.
- It makes browser-native video editing feel much more self-contained.
Why the warning exists
- It is still experimental in Remotion.
- Some CSS, layering, media, and component behavior is limited.
- Browser support and device performance can affect the result.
The Simple Summary
Server-side rendering is like sending the video to a professional kitchen. It costs money, but the kitchen is built for the job.
Client-side rendering is like cooking at home. It can be faster and cheaper, but now your browser, device, and ingredients matter.
For RVE, the important point is this:
RVE gives you the editor and rendering hooks. You decide whether your product should render locally in the browser, use a custom client-side render flow, or send jobs to a server-side render pipeline.
FAQ
What is server-side rendering?
It means the render happens on a server, worker, or cloud service. Your browser sends the job away and downloads the finished video later.
What is client-side rendering?
It means the render happens directly inside the user's browser, using the user's device.
Is client-side rendering free?
It avoids server render costs, but it is not "free" in the physical sense. The user's device still does the work.
Why does the RVE demo warn me?
Because Remotion client-side rendering is experimental and has limitations. The warning is there so you understand that local browser export is not the same as a full production server render.
Should I use client-side rendering in production?
You can evaluate it carefully for controlled use cases. For large-scale, high-reliability rendering, server-side rendering is still usually the safer production path.
Next step
Client-side rendering is exciting, but it is still a tradeoff
If you are building with RVE, the right question is not just whether browser rendering works. It is whether your product needs local exports, server-side reliability, or a custom render path.
