Skip to main content

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:

src/editor/flags.ts
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​