The Three-Renderer Rule: How to Preview, Edit, and Export Video with One Schema

In the traditional video engineering world, the path from a "draft" to a "final render" is often a fragmented mess of incompatible formats. You might design a motion graphic in After Effects, export a low-res proxy for a web preview, and then fight with FFmpeg shell scripts on a server to recreate that same look for the final MP4.

This fragmentation isn't just a workflow headache; it's a scaling bottleneck. If your preview doesn't match your render, your users (or your automated pipelines) are flying blind. At VideoFlow, we solved this with what we call the Three-Renderer Rule: one portable schema, rendered identically across three specialized engines.

The Architecture of Portable Video

The core of VideoFlow is the VideoJSON schema. Unlike React-based video frameworks that tie your scene logic to a specific UI runtime, VideoFlow treats a video as a pure data structure.

When you use the @videoflow/core builder, you aren't just "coding a video"; you are compiling a portable document that describes every layer, keyframe, transition, and GLSL effect in a resolution-agnostic format.

Because the schema is pure JSON, it doesn't care where it's rendered. This leads us to the three official renderers that make up the VideoFlow ecosystem.

1. The Live Preview: @videoflow/renderer-dom

If you're building a video editor or a SaaS dashboard with a "Preview" button, you need frame-accurate feedback at 60 fps. You can't wait for a server to return an MP4 every time a user changes a text color.

@videoflow/renderer-dom takes your VideoJSON and renders it directly to the DOM. It uses the same easing logic and property resolution as the heavy-duty renderers but optimizes for real-time scrubbing and playback. This is the engine behind our Playground, allowing for a seamless "what you see is what you get" experience.

2. The Client-Side Export: @videoflow/renderer-browser

One of the biggest costs in video automation is server-side rendering. Why pay for expensive GPU instances in the cloud when your user's browser is perfectly capable of encoding video?

@videoflow/renderer-browser uses the modern WebCodecs API to export professional-grade MP4s entirely client-side. It handles the rasterization of layers, the application of cinematic GLSL effects, and the audio mixing, then spits out a blob that the user can download instantly.

3. The Headless Powerhouse: @videoflow/renderer-server

For batch jobs, scheduled social media posts, or personalized video at scale, you need a server-side solution. @videoflow/renderer-server runs in Node.js and drives a headless Chromium instance via Playwright.

Crucially, it produces byte-for-byte identical output to the browser renderer. You can develop and preview your video in the browser, hit "Save," and know with absolute certainty that the server-side render will look exactly the same.

Why the Three-Renderer Rule Wins

By following this rule, developers gain three massive advantages:

1. Zero-Re-implementation: You don't have to write "preview logic" in JavaScript and "render logic" in FFmpeg. You write your video once using the VideoFlow Builder API.
2. Infrastructure Flexibility: You can start by rendering everything on the client to save costs, and move heavy jobs to the server as your needs grow, without changing a single line of your video definition.
3. Agent-Friendly Pipelines: Because the video is just JSON, it's trivial for LLM agents to generate. An agent can emit a VideoJSON document that you can immediately preview in a React component and then send to a server for final processing.

Example: One Script, Three Destinations

Here is how simple it is to build a video that is ready for all three renderers:

import VideoFlow from '@videoflow/core';

const $ = new VideoFlow({ width: 1920, height: 1080, fps: 30 });

// Add a background image with a blur effect
const bg = $.addImage(
  { fit: 'cover', opacity: 0.8, effects: [{ effect: 'gaussianBlur', params: { radius: 0.5 } }] },
  { source: 'https://images.unsplash.com/photo-1618005182384-a83a8bd57fbe' },
);

// Add a title with a built-in transition
const title = $.addText(
  { text: 'The Three-Renderer Rule', fontSize: 8, color: '#FF5A1F' },
  { transitionIn: { transition: 'blurResolve', duration: '800ms' } }
);

$.wait('3s');

const json = await $.compile();
// Now send this 'json' to renderer-dom, renderer-browser, or renderer-server.

Get Started with Portable Video

Whether you're building a YouTube Shorts factory, a personalized onboarding flow, or an embeddable video editor, the architecture of your pipeline matters. Don't lock your creative assets into proprietary formats or fragile shell scripts.

Explore our official renderers guide to see how you can implement the Three-Renderer Rule in your next project, or head over to GitHub to see the source code for yourself.