Every video tool I have used online has a render queue. You press export, a progress bar appears, and somewhere a server picks up your job behind the twelve people ahead of you. On a busy evening that is a five-minute wait for a twenty-second clip.
Dingcut does not have a queue. When you press Export the video is encoded on your machine, in the browser tab, and the MP4 lands in your downloads a few seconds later. This post is about how that works and why I built it that way.
The short version
Modern browsers ship WebCodecs, an API that gives JavaScript direct access to the hardware video encoder. Dingcut draws each frame to a canvas, hands the frame to the H.264 encoder, mixes the audio, and muxes the result into an MP4 using Mediabunny. Nothing leaves your computer except the final file if you choose to upload it.
Why not a server
Three reasons, in order of how much they mattered.
The first is cost. A render server costs money per video. A free tier on a render server is a bet that free users will not use it much. That bet always loses eventually. With browser rendering, a free user exporting a video costs me nothing, so the free tier can be real: three exports, no credit card, no daily limit tricks.
The second is speed. A 1080x1920 twenty-second clip at 30fps is 600 frames. A laptop with a hardware encoder does that in under ten seconds. A server would take about as long to encode, plus upload, plus queue, plus download.
The third is that preview and export share one renderer. The video you watch in the editor is drawn by the same code that draws the export. There is no "it looked different in preview" bug because there is no second implementation.
What you need
Chrome and Edge have had WebCodecs for years. Firefox added it in version 130. Safari caught up in Safari 26. If you are on an older browser, the editor still works and you can write and preview, you just cannot export.
Hardware encoding is used where the browser exposes it. On machines without it, encoding falls back to software and takes a bit longer. Still faster than a queue.
How the free tier is enforced if the render is local
This is the question every developer asks. If the browser does the rendering, what stops someone from removing the watermark?
Every export asks the server for a signed render ticket. The ticket carries the duration cap and the watermark flag, signed with a secret the browser does not have. The renderer reads the limits from the ticket. The server counts completed tickets per user and stops issuing them past the free limit. A determined person could patch the client, and I have made peace with that. The people who would do it were never going to pay $2.99, and the people who would pay do not want to fight their tools.
Audio
The sound library is 49 clips synthesized in-house, so there are no licensing questions on exports. The mix is done with the Web Audio API, rendered offline to a buffer, then encoded to AAC alongside the video. Product sounds are placed to the frame, which is what makes the ding land on the beat.
What this means for you
Export is a few seconds. There is no upload of your project to a render farm. Re-exporting in a different skin is another few seconds. You can iterate on timing by exporting, watching on your phone, adjusting one line, and exporting again, without the cost of a round trip.
That loop is the whole reason the product exists. Try it at dingcut.xyz/new.