clip-js: a browser video editor that previews with Remotion and exports through ffmpeg

The gap clip-js targets sits between a phone clip and a desktop NLE

clip-js is an online video editor that runs in the browser. It is built with Next.js, uses Remotion for real time preview, and uses ffmpeg through a WebAssembly port for the export step. The audience is narrow and fairly clear: someone who has a few clips to trim, split, layer and export, and who does not want to install a desktop editing suite or hand raw footage to a hosted service.

The MIT licence matters for that audience, because it lets anyone fork the app and run it on infrastructure they control. The deployment shape is a standard Next.js project, and the demo site lives at clipjs.mohy.dev. Looking at the dependency list, the whole product surface is a React and Redux application with a canvas, a custom timeline, the Remotion player, the ffmpeg WebAssembly packages, and a browser storage layer. There is no account system, no media server and no collaboration service in that list, which is the clearest signal of what the project is and is not trying to be.

Remotion drives the preview frame while the WebAssembly ffmpeg port does the export

The two halves of the pipeline are deliberately different technologies, and the reason is worth stating plainly. Remotion renders React components as video frames, which makes it a good fit for drawing a timeline in a browser and having it update as you drag. ffmpeg is the encoder. The project pairs @remotion/player and @remotion/media-parser with @ffmpeg/ffmpeg and @ffmpeg/util, the latter described as a WebAssembly port of ffmpeg used for the high quality render with several export options.

Around that core sit the usual editor plumbing: @reduxjs/toolkit with react-redux for state, idb for browser side persistence, and moveable together with react-moveable for on canvas manipulation. The repository uses the Next.js app directory, with the app/, public/ and images/ directories alongside next.config.js, tailwind.config.ts and a root dockerfile. Per element controls cover position, opacity, z index and volume, so the canvas is where the shape of a frame is decided and the timeline is where the order of frames is decided.

Cloning the repo and starting the dev server

The project ships source rather than a published package, so the install path is a clone. package.json is named clipjs, sits at version 0.1.0 and is marked private, which means npm install is a dependency step, not a distribution route. The README gives the sequence directly: clone the repo, then install dependencies.

npm install

After that, start the development server.

npm run dev

For a production build, the scripts are build followed by start.

npm run build
npm start

The container route is the shortest path for anyone who does not want a Node toolchain on the host. A dockerfile and a .dockerignore sit at the repository root, and the README documents building the image and starting the container on port 3000.

# Build the Docker image
docker build -t clipjs .

# Run the container
docker run -p 3000:3000 clipjs

Either way, the entry point is the local server on port 3000, where the editor and its canvas load. A first real use is short: import a video, drag it on the timeline, split it, then export. There is no separate command for the export step in the scripts, so it is triggered from the running application.

Split, duplicate and layer is the whole editing model

The feature list is short and it clusters around one idea: rearrange existing media rather than transform it. The custom built timeline exists to arrange, trim and control media, and the element utilities cover splitting, duplicating and managing individual media layers. Media of mixed kinds can be combined, so video, audio tracks, images and text elements can sit on the same timeline. Keyboard shortcuts are provided for the common operations: play, mute, move in time with the arrow keys, split and duplicate.

That set of capabilities describes a linear trim and arrange editor. Nothing in the description mentions transitions, filters, speed changes, keyframes, colour grading, or caption files, and the dependency list contains no charting, colour or subtitle packages. Remotion could support richer effects, but the code as described does not expose them, so anyone planning a title sequence with animated layers will not find the building blocks for it here. The project also points readers at a TODO.md file for prioritised tasks and asks for contributions, which suggests the feature set is still moving rather than frozen.

The 1080p export cap and the in tab encoder are the two real limits

Export is documented as supporting up to 1080p, and that ceiling comes from the encoder path rather than from the timeline. The second limit is where the render runs. ffmpeg here is a WebAssembly build executing inside the browser, so export time depends on the speed of the machine doing the work and the memory headroom of the tab. A one minute clip behaves very differently from a fifteen minute project, and the difference shows up as a long running export that the user is waiting on with the tab open. There is no server side render queue in the dependency list to hand that work off to.

Media handling has its own edge. @remotion/media-parser is used to read media metadata, and the README does not document which container formats, codecs or audio tracks are supported. Neither does it document how uploaded media is stored beyond the presence of idb as a dependency, and basehub also appears in the dependency list without an explanation of its role anywhere in the README. The rollback story is equally quiet: the README does not document rollback, so a bad export is something you retry rather than undo.

How a native ffmpeg pipeline differs from encoding in the tab

The honest alternative is not another web editor, it is a native ffmpeg command line pipeline, because that is the tool this project embeds. The difference in approach is where the code runs and who waits for it. A native pipeline encodes on a workstation or a build machine, so it has the whole CPU and the whole filesystem, and it is not bound by the 1080p figure that the WebAssembly port advertises. Its cost is that you lose the interactive canvas, the timeline you can drag, and the live preview.

The trade is a real one, and it maps to how the work is done. clip-js is a better answer when a person is deciding frame by frame what a ten second cut should look like. A native pipeline is a better answer when the edit is already decided and the work is rendering, transcoding or batching. A desktop editor sits in between, giving the same visual control without holding the render inside the browser tab. Nothing in clip-js blocks you from exporting a finished timeline and processing it elsewhere, but the project does not document that path either.

MIT licence, no releases, and a last push on 2026-08-03

The licence is MIT, and a LICENSE file sits at the repository root, so forking and self hosting are straightforward. The upgrade cost is where the caution belongs. The repository has no GitHub releases, which means there is no changelog, no version history to diff and no release notes to read before a bump. You are adopting whatever sits on the main branch, so pinning a commit is the sensible move for any deployment you have to keep running.

The last push was on 2026-08-03, so the project is not abandoned and it is not archived, but the gap between pushes is over two months and no release has been cut from it. Two dependency choices deserve attention. Both @ffmpeg/ffmpeg and @ffmpeg/util are declared with the wildcard version, so a fresh install can pull a different encoder build than the one your team last tested, which is a quiet way for a browser render to change output. Separately, eslint-config-next is pinned to 13.4.13 while next is on the 14 line, so the lint configuration trails the framework by a major version and the lint script may need a second look.

Editorial conclusion

clip-js suits solo creators trimming short clips in a browser tab, and suits teams less well when projects run long, need 4K, or have to be shared across machines, because export is capped at 1080p and editor state lives with the browser. Before adopting it, render one of your own long projects on the hardware your users actually have and time the export, then pin the two @ffmpeg packages to the exact versions you tested, since both are declared with a wildcard range.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mohyware/clip-js on GitHub
4. Project website
5. README