Client-side rendering in the Editor Starter

The Editor Starter can render videos in the browser using @remotion/web-renderer.

Enable client-side rendering

This feature is disabled by default.
Set ENABLE_CLIENT_SIDE_RENDERING to true:

export const ENABLE_CLIENT_SIDE_RENDERING = true;

FEATURE_NEW_MEDIA_TAGS must also be enabled (which it is by default).

You do not need to configure the REMOTION_AWS_* environment variables or run deploy.ts for rendering.

:::note Other Editor Starter features may still need backend routes or AWS credentials. For example, text rendering loads font metadata from /api/fonts/:name, asset uploads use Amazon S3, and captioning uses a backend route. :::

How it works

When the user clicks Render, the Editor Starter:

1. Collects the current tracks, items, assets, composition settings, and font metadata.
2. Passes the composition directly to renderMediaOnWeb().
3. Encodes the video in the browser using WebCodecs.
4. Creates a temporary blob URL and shows the completed render in the task indicator, where it can be downloaded.

Unused Lambda routes

The /api/render and /api/progress routes are not used for client-side rendering.
However, by default, assets still upload to S3.

Main tradeoffs

• The user can leave the page when rendering on Lambda, but not with client-side rendering.
• Client-side rendering avoids Lambda compute costs. Remotion licensing, S3 asset storage, and bandwidth costs may still apply.
• The browser must support WebCodecs, and the composition must work within the limitations of client-side rendering.
• Client-side rendering may make the page less responsive.
• Lambda is generally better suited to long or distributed renders.
• More codecs are supported on Lambda, such as ProRes.
• Client-side rendering creates a temporary blob URL. Unlike Lambda output in S3, it is not persisted automatically.

See also

• Rendering with Remotion Lambda in the Editor Starter
• Client-side rendering
• How client-side rendering works
• Limitations of client-side rendering