@clipkit/editor is the open-source video editor built for the web: an Apache-2.0 timeline editor that runs entirely in the browser, embeds in your product as a React component, and treats every video as data your software (and your AI agents) can write. GPU-accelerated preview, free MP4 export on the user's own machine, your storage underneath. It's live on this site as a no-login demo you can open right now.
Most results for this search are desktop apps for cutting footage (Shotcut, Kdenlive, DaVinci Resolve, which is free but not open source), and that's a different job: a human at a workstation editing filmed material. This page is about the editor those apps can't be: one that ships inside products, renders deterministically from an open JSON protocol, and works as the human surface of an agent pipeline. That category has exactly one open-source editor built for it, and this is it.
What it is#
@clipkit/editor is a React component that renders a full timeline editor: tracks, clips, keyframes, text, shapes, media, captions, audio. Under it sits @clipkit/runtime, a deterministic GPU compositor (WebGPU, with a WebGL2 fallback), so the preview you scrub is pixel-identical to the file you export. The document being edited is JSON conforming to the Clipkit Protocol, an Apache-2.0 spec, which is why the editor can be one participant in a larger pipeline instead of a walled garden: your backend can generate that JSON, an agent can write it, and a human can polish it on the timeline.
The whole embed is three lines:
import { Editor } from "tok-str">'@clipkit/editor'; <Editor initialSource={project} />;
That's the full editor: every panel, keyframes, expressions (ADVANCED_CONFIGURATION, the default). A configuration is plain data over the same component tree, so slimming it down is a prop, not a fork: pass BASIC_CONFIGURATION for a streamlined surface, or define your own and show exactly the views your users need.
Your storage, not ours#
The editor library contains zero database code. Media flows through an AssetStore port you inject:
import { createLocalAssetStore } from "tok-str">'@clipkit/editor'; const assetStore = createLocalAssetStore(); "tok-cmt">// browser IndexedDB, the default
Two stores ship in the box (browser-persistent and in-memory), and pointing at S3, Supabase, or your own API means implementing one interface and passing it as a prop. Persistence of the document itself is just as unmagical: onSourceChange hands you the JSON on every edit and you put it wherever you keep data. There's no Clipkit account in the loop, no iframe pointing at our servers, no usage phone-home. Your app owns the editor the way it owns a date picker.
What "open source" means here, precisely#
Devs check licensing claims, so here's the exact shape of the stack (the architecture page has the long version):
| Piece | License | What that means |
|---|---|---|
@clipkit/editor (the UI) | Apache-2.0 | Use, modify, ship commercially. |
| Clipkit Protocol (the JSON spec) | Apache-2.0 | Independently implementable. |
@clipkit/renderer (local headless renders) | Apache-2.0 | Render on your own hardware. |
@clipkit/runtime (the GPU engine) | BSL 1.1 | Source-available. Free for dev, test, and non-commercial use without limits; free in production up to 250 rendered output-minutes per month. Each release becomes Apache-2.0 four years after it ships. |
In plain terms: the editor you embed is open source, and the engine it previews and exports through is source-available with a free production tier and a scheduled conversion to open. If your product renders more than 250 output-minutes a month in production, that's the point where a commercial license enters. Below it, the stack costs nothing to ship.
Export without a render farm#
Export runs through WebCodecs on the user's own GPU, produces an MP4, and never touches a server: no render farm to build, no per-export cost, no watermark. On modern hardware it's fast (we measure roughly 222 fps for 1080p export on an Apple M4, over 7x realtime), and speed scales with the GPU doing the work (an older Intel i9 manages 4 to 5 fps), which is exactly what the server-side path is for.
When you outgrow that (server-side pipelines, guaranteed speed, ProRes / AV1 / alpha output), the same JSON renders on hosted GPUs or through @clipkit/renderer on your own hardware. Nothing about the document changes; only where pixels get computed does.
Built for software, which now includes agents#
A desktop editor's document is a project file only that editor understands. This editor's document is a validated JSON schema, and that difference compounds. Videos can be generated from a database row, templated per user, diffed in code review, and authored by an AI agent over MCP. The pattern we see working in production is machine-drafts, human-polishes: an agent (Claude, or your own pipeline) writes the Source document, and a person opens it in this editor for the last 10% of judgment a timeline is good at. In our 60-cell agent benchmark, agents authoring against the schema shipped a valid video on 15 of 15 attempts, which is what makes the machine half of that loop dependable.
If you're evaluating this stack against writing videos as React code, the honest comparison with Remotion is here, including where Remotion wins.
A different job than a desktop NLE#
Desktop editors are built for footage-first work: multicam cuts, color grading, effects plugins, a human at a workstation. Clipkit's editor is built for video that lives inside software: composed, programmatic, data-driven video, with footage as one element type on the timeline (trim, layer, position, caption). The two categories barely overlap, and the distinction cuts both ways: a desktop NLE can't embed in your app, can't be authored by your backend or an agent, and doesn't produce a diffable, validatable document. If your job is footage-first film editing, use an NLE. If video is a capability your product ships, that job has an open-source editor purpose-built for it, and you're reading its page.
Try it, then embed it#
The no-login editor on this site is the stock component running against a demo storage adapter, which makes it both the demo and the reference integration. Open it, build something, export an MP4, and you've exercised the exact code path your users would get. Then:
npm install @clipkit/editor
The editor docs cover props, configurations, storage adapters, and theming; the architecture page explains how the editor relates to the protocol, the runtime, and the agent tooling around it.