# Omniclip browser video editor: components, setup, and limitations

> Omniclip is a TypeScript video editor that processes media in the browser, offers custom elements for embedding, and does not require an account or cloud storage. Its WebCodecs dependency makes browser support and unfinished editing features important adoption constraints.

**omni-media/omniclip** — Open source video editing web application

- Repository: https://github.com/omni-media/omniclip
- Website: https://omniclip.app/
- Stars: 1,468 · Forks: 120
- Language: TypeScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/omni-media-omniclip

## Omniclip's local editing and embedding scope

Omniclip addresses two related needs. First, it provides a browser video editor whose media remains on the user's device. The README states that the application requires no accounts, never uploads files, and can run without cloud services or subscriptions. Second, it exposes editor components that another web application can register and place on a page. This makes the project relevant to developers building a custom video-editing interface as well as to people who want an editor that operates locally.

The documented editing surface covers trimming, splitting, timeline-based media, text styling, rotation, resizing, undo and redo, transitions, filters, and selectable frame rates from 10 to 120 fps. Rendering can target resolutions up to 4k. The project manager stores and selects multiple saved projects, while the README also lists collaboration through WebRTC. That collaboration feature is mentioned without a documented setup procedure, so its deployment expectations and persistence behavior cannot be inferred.

Omniclip is not presented as a replacement for every stage of professional post-production. Audio editing, including volume adjustment, speech-to-text, and keyframes are listed under "To be added." Projects that depend on those controls would therefore need another editor for now.

## Browser-side media processing with WebCodecs

The central technical constraint is that Omniclip performs video processing in the browser. The README specifically names WebCodecs as the modern browser API used for high-performance rendering. This architecture means decoding, preview rendering, and output generation are tied to the capabilities of the browser and device rather than to a documented server-side media pipeline.

That choice can reduce cloud dependencies, but it also transfers compatibility and resource demands to the client. The README warns that older browsers and devices without the required browser technologies may not work properly. The repository dependencies reinforce the browser-focused design. They include `@types/dom-webcodecs`, `ffprobe-wasm`, `@ffmpeg/ffmpeg`, and `@zip.js/zip.js`, indicating that Omniclip combines native browser media interfaces with WebAssembly and archive-related tooling. The documentation does not describe exact decoding limits, memory ceilings, render times, or supported output codecs.

The build scripts also copy `coi-serviceworker.js` and assets into the generated `x/` directory. This supports the repository's static browser distribution model, but the README does not explain what deployment headers or cross-origin isolation settings a host page must configure. Those details need direct verification in the application environment.

## State, actions, controllers, and view components

The README identifies four layers for application state: State, Actions, Controllers, and Components/Views. It describes the flow as unidirectional. User or application events become actions, actions update state, and components render from that state. Controllers sit within this arrangement, although the README does not define their exact responsibilities or show a complete state-transition example.

This design is useful for a custom web editor because it separates interface elements from state changes. The exported integration functions also indicate that the editing interface is composed from custom DOM elements. `getComponents()` supplies components, and `registerElements()` registers them with the DOM. The documented elements cover text, media, and timeline concerns. A host can therefore expose selected parts of the editor rather than loading the whole interface.

The primary package metadata identifies the package as `@omnimedia/omniclip` at version `1.1.3`. It is an ES module whose `main` entry is `x/index.js`, and its published `files` list contains `x` and `s`. By contrast, the component tutorial says to install `omniclip`. That difference matters for an engineer because package resolution depends on exact names.

## Installing Omniclip for a first embedded editor

The README gives this package installation command for component use. It preserves the unscoped package name documented in the tutorial, although `package.json` names the repository package `@omnimedia/omniclip`.

```bash
npm install omniclip
```

After installation, the documented integration registers the components. The import and registration call are shown in JavaScript because the README uses a JavaScript example, even though the project's primary language is TypeScript.

```js
import {getComponents, registerElements} from 'omniclip'
registerElements(getComponents())
```

A host page can then place the elements it needs. The README shows all three documented components, which provide text, media, and timeline surfaces.

```html
<omni-text></omni-text>
<omni-media></omni-media>
<omni-timeline></omni-timeline>
```

A first real use is loading the registered page in a browser that supports the required media APIs, then adding the desired custom elements. The README does not provide a media-import click sequence, sample project, expected output file, or rendered preview, so it would be misleading to invent one. For contributors, it documents a separate build workflow using clone, install, build, and start commands.

## Building the Omniclip repository from source

The contributor instructions use an SSH clone URL, followed by dependency installation, a production-style build, and a watch-mode development command. The README spells the repository name as `omniclip`, although the repository identifier is `omni-media/omniclip`.

```bash
git clone git@github.com:omni-media/omniclip.git
npm install
npm run build
```

After cloning, `npm install` resolves the dependencies recorded by the repository. `npm run build` invokes `turtle-standard` and then runs the `copy-coi` and `copy-assets` scripts. In `package.json`, those scripts copy `coi-serviceworker.js` from `node_modules/coi-serviceworker` into `x/` and copy the repository's `assets` directory there.

The documented development command starts `turtle-standard-watch`. That is the relevant first command after completing the initial build.

```bash
npm start
```

The repository also defines a test command, but the README does not describe it as part of contributor setup.

```bash
npm test
```

The test script runs `cynic node ./x/tests.test.js`. That file is generated into `x/` by preparation scripts and is not shown as a top-level source entry, so contributors should verify whether their build has produced it before expecting a useful result.

## Omniclip versus a programmatic timeline engine

The clearest alternative described by the project is Omni Tools, a separate repository that the README says will eventually power programmatic Omniclip tools. Their approaches differ. Omniclip presents a browser editing interface with custom elements for media, text, and timeline work. Omni Tools is described as a programmatic engine for creating timelines from code, automating rendering, and integrating with AI or scripting workflows.

That distinction makes Omni Tools the more relevant concept for automation that does not need a graphical editor. A script can express a timeline without depending on users operating preview controls, whereas an Omniclip embedding approach requires the host page to provide components and the browser to provide media capabilities. The README does not say that Omni Tools is available inside Omniclip yet. It explicitly says the tool is still in early development and that tool documentation will be added once available.

For ordinary nontechnical editing, a conventional desktop video editor is the practical alternative because Omniclip currently lacks documented audio volume controls, speech-to-text, and keyframes. For developers, however, the meaningful comparison is interface-driven editing versus code-driven timeline construction, not browser editing versus hosted cloud editing.

## Release history, upgrade work, and license ambiguity

The repository is not archived, and its last push was on 2026-10-15. That supports recent repository activity, although it does not establish release cadence or API stability. GitHub has no published releases for this repository. Versioning is visible in `package.json`, which reports `1.1.3`, while the README announces that Omniclip 2.0 is in development. There is no migration guide, upgrade policy, or compatibility statement for moving between those lines.

The documented build pipeline adds upgrade cost. A fresh package build depends on `turtle-standard`, parallel script execution, asset copying, service worker copying, and later packaging steps such as `prepare-x`. The published package also embeds `node_modules` into `x/` according to `prepare-x`. An engineer adopting the library must account for this generated distribution structure rather than assuming the repository layout is directly deployable.

There is also a license metadata conflict. The README and its badge identify the project as MIT and point to `LICENSE`, but the `license` field in `package.json` says `ISC`. The available documentation does not resolve which terms apply to downstream distribution. That is a concrete packaging issue to check against the actual `LICENSE` file and the project owner before including `@omnimedia/omniclip` in a released product.

## Conclusion

Omniclip fits engineers building a browser-based editor or local editing workflow, as well as users who prioritize files remaining on their devices. It is less suitable for work that currently depends on audio controls, speech-to-text, keyframes, older browsers, or unambiguous licensing metadata. Verify the WebCodecs and filesystem APIs in the target browsers, resolve the MIT and ISC discrepancy, and confirm that the packaged `x/` entry works in the intended host application before adopting it.

## FAQ

### Does Omniclip upload my video files?

The README states that Omniclip stores everything on the user's device and never uploads those files. Collaboration through WebRTC is listed as a feature, but the README does not explain how it handles media or project data.

### Which browsers and devices support Omniclip?

The README does not list specific supported browsers or minimum versions. It says the editor may not work properly on older browsers or devices that do not support newer technologies such as WebCodecs.

### How do I embed the Omniclip editor in a web application?

The README uses `npm install omniclip`, then imports `getComponents` and `registerElements`, registers the components, and places custom elements such as `<omni-text>`, `<omni-media>`, and `<omni-timeline>`. The repository metadata names the package `@omnimedia/omniclip`, so the discrepancy should be checked before installation.

## Sources

- [Issues](https://github.com/omni-media/omniclip/issues)
- [License: MIT](https://github.com/omni-media/omniclip/blob/main/LICENSE)
- [omni-media/omniclip on GitHub](https://github.com/omni-media/omniclip)
- [Project website](https://omniclip.app/)
- [README](https://github.com/omni-media/omniclip/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/omni-media-omniclip