tooscut: a browser video editor built on WebGPU and Rust

A non-linear editor in a browser tab

tooscut is a non-linear video editor that runs entirely in the browser, and the short version of what it is made of is Rust, WebGPU, WebAssembly and TanStack Start.

The feature list is the familiar one for an editor of this kind, with the technology attached to each item. GPU-accelerated rendering, with WebGPU compositing done through Rust and WASM for near-native performance. A multi-track timeline, Canvas-rendered, with unlimited video and audio tracks. Keyframe animation, where any property can be animated with bezier easing curves. Real-time effects for brightness, contrast, saturation, blur and hue rotation. A local-first design, where all the media stays on your machine through the File System Access API. And zero install, which is just the opening of a browser and the start of an edit.

The last two are the interesting ones. A browser editor that keeps your footage on your disk is not a small privacy nicety, it is the difference between a tool you can use and a tool you cannot use, because the alternative is uploading a wedding video to somebody's server. The File System Access API is the mechanism, and it is a browser API with real limits, which is where the project's own rough edges are most likely to be.

The project is private on the package registry at version 1.0.0, the site is tooscut.app, and the last push to the repository was on 2026-10-12. There are no GitHub releases, so what you can get today is the source.

The compositor is Rust compiled to WebAssembly

The Rust side of the project is the interesting part, and the Cargo workspace describes it precisely.

The workspace has four member crates, crates/types for the shared types, crates/keyframe for the keyframe model, crates/audio-engine for the audio, and crates/compositor, which is the piece that does the rendering. The workspace uses the resolver 2 setting, the edition is 2021, and the shared workspace version is 0.1.0.

The GPU stack is wgpu at version 24 with the default features turned off and three features enabled, webgpu, webgl and wgsl. That feature list is a decision in itself, because it means the same compositor code can run on a native WebGPU device, on WebGL 2 for browsers without WebGPU, and with WGSL shading, so a machine without the newest browser still gets a working editor.

The bridge to JavaScript is the standard Rust to web stack, wasm-bindgen with its futures variant, js-sys, web-sys, tsify-next for the TypeScript bindings, and serde-wasm-bindgen for the serialisation across the boundary.

And the web-sys feature list is where you can read the design. It names the WebGPU types the compositor touches, GpuDevice, GpuAdapter, GpuQueue, GpuCanvasContext, GpuTexture, GpuTextureView, GpuBuffer, GpuBindGroup, GpuRenderPipeline, GpuCommandEncoder and GpuRenderPassEncoder, alongside OffscreenCanvas, ImageBitmap and the WebGL 2 rendering context, which is the fallback path. The text rendering is handled by glyphon and cosmic-text, so the editor can draw labels on the GPU without shipping a font rasteriser in JavaScript.

The release profile is tuned hard, with size optimisation, link time optimisation, a single codegen unit and panic set to abort, and the development profile keeps the optimisation level at one so the Rust build stays fast while you work.

A TanStack app, a shared package and a workspace

The repository is a monorepo, and the architecture section of the readme draws the whole of it:

tooscut/
├── apps/ui/             # TanStack Start app (React 19)
├── packages/
│   └── render-engine/   # @tooscut/render-engine (types, keyframes, compositor)
└── crates/              # Rust WASM (compositor, keyframe, shared types)

Three layers, and each one has a reason to exist. The application is a TanStack Start app on React 19, which is the full stack React framework, so the routing and the server side rendering are part of the application layer rather than something bolted on. The render engine is a separate TypeScript package, published under the @tooscut scope, holding the types, the keyframes and the compositor interface, so the parts that are shared between the application and the WebAssembly module have a single home.

And the Rust crates are the implementation behind that interface, the compositor, the keyframe maths and the shared types. The Cargo workspace also declares two internal crates as path dependencies, tooscut-types and tooscut-keyframe, which is how the crates reference each other without going through the registry.

The readme points at a CLAUDE.md file for the detailed architecture documentation, and the repository confirms it, with the file at the root alongside a CLA.md, a .claude directory, a .cursorrules file, an .agents directory and a .mcp.json configuration. In other words, the architecture is written down for a coding assistant to read, which is a reasonable way to keep a monorepo with two languages and four crates navigable.

Turborepo, oxlint, oxfmt and knip

The JavaScript side of the build is small and modern, and the package manifest is worth reading in full because it is short.

Every task goes through Turborepo, with dev, build, typecheck, test and clean all delegated to it, and the workspace is defined by a turbo.json at the root. The linting is oxlint with the type-aware flag and the correctness rules denied, so a lint failure is a correctness failure rather than a style preference, and the formatter is oxfmt with a check mode for continuous integration and a write mode for the fix. Both oxlint and oxfmt are pinned to a catalog, the pnpm feature that lets a workspace share one version of a tool across packages, so the lint rules do not drift between the application and the render engine.

Two more tools are there for a reason. knip is the dead code detector, and its configuration lives in a knip.json at the root, which is the sort of tool a project with a Rust and TypeScript boundary needs, because the boundary is exactly where unused exports hide. Playwright is in the development dependencies, and there is a script that takes the documentation screenshots.

The WASM build is a separate step, because it is a separate toolchain, and the command says so:

pnpm build:wasm   # Build WASM compositor (requires Rust + wasm-pack)

So the working loop has two halves. The front end runs with pnpm dev on port 4200, and the Rust side is rebuilt with a script in the crates directory that needs a Rust toolchain and wasm-pack installed. That is the cost of the architecture, and the readme is honest about it rather than hiding the Rust requirement in a Docker image.

The licence is declared three different ways

There is a genuine inconsistency in this repository, and it is the kind of thing to raise before you build on it rather than after.

The readme states the licence as the Elastic License 2.0, with a link to the Elastic licensing page. The Cargo workspace declares the licence as MIT in its shared package metadata. The package manifest for the JavaScript side declares ISC. And the licence field that the hosting platform shows for the repository points at a licence file that the platform cannot classify.

The Elastic License 2.0 is a source-available licence, not an open source one, which is a meaningful difference for a project of this kind, and it does not match MIT or ISC. So one of the three declarations is out of date, or the intent changed and the manifests were not updated.

The practical advice is to read the LICENSE file yourself and, if you are planning to redistribute or to use the project commercially, ask the author. The choice between a permissive licence and a source-available one with a commercial restriction is exactly the kind of thing that is decided deliberately and then written down in one place, and the fact that three places disagree suggests the decision has not been propagated.

Nothing else in the repository suggests a licensing problem, and the code itself is ordinary work, but the paperwork is the part you have to get right.

The project is young and the version numbers disagree too

The version numbers tell the same kind of story.

The package manifest is at version 1.0.0, the Cargo workspace at 0.1.0, and the repository has no GitHub releases at all. So there is no published artefact to install, and the two version numbers in the repository describe different things, the JavaScript application and the Rust workspace, which is defensible but not obvious.

What the repository does have is a set of tools for keeping track of work in progress. There is a .beads directory, which is a lightweight issue tracker that keeps its state in the repository, a skills-lock.json, a scripts directory with the documentation screenshot tool, a CONTRIBUTING.md and a .github directory. The scripts directory and the screenshot script in particular suggest that the documentation images are generated rather than pasted, which is the right approach for an application whose interface changes.

There is also a signatures directory, and a .devcontainer is not present but the .vscode directory is, with an .oxfmtrc.json and an .oxlintrc.json at the root for the two tools that do the formatting and the linting.

Taken together, this is a project that is being built in public with the tooling for that in place, and that has not yet decided what it ships as. For an evaluator, that is the honest summary, and the two questions to ask the author are the licence and the release plan.

Editorial conclusion

tooscut fits a developer who wants a video editor that runs in a tab, with no install and no upload of private footage, because the compositor is a Rust and WebAssembly module talking to WebGPU and the media is opened through the browser's own file system access. It is the wrong choice if you need a desktop application today, since everything here is a web application and the project publishes no releases, only source, and it is the wrong choice if you need a defined licence, because the readme, the package manifest and the Cargo workspace each declare a different one. Before you build on it, read the architecture document and the CLAUDE.md file, and decide whether you can live with a licence that is still being settled, because that question is not a detail for a tool that handles somebody's holiday footage.

Frequently asked questions

Official sources

1. Issues
2. mohebifar/tooscut on GitHub
3. Project website
4. README