How ClipHeron works, and how to check it

What runs where

ClipHeron is a static website. There is no upload endpoint, no processing server, no queue and no database of files, because there is nothing for one to do. When a tool needs the engine for the first time, your browser fetches it from clipheron.com like any other script (about 2 to 3 MB, once, then cached); that file is identical for every visitor and the request contains nothing about your video.

The engine, and WebCodecs

Two things do the heavy work. The first is an open-source video engine written in Rust and compiled to WebAssembly, which reads MP4, MOV, WebM and MKV containers, finds every frame and keyframe, copies samples into new files for lossless trims and audio extraction, writes GIFs, and decodes and encodes video in software when nothing better is available. Its components and licences are listed on the licences page. It runs single-threaded on purpose: the browser feature that would let it use several threads also blocks the ads that pay for the site, so parallelism comes from somewhere else.

That somewhere else is WebCodecs, a browser API that gives a page direct access to the same hardware video decoders and encoders the camera app and the video player use. Where it is available (Chrome and Edge on most computers and Android phones, Safari on recent Apple devices), the engine only takes the container apart and puts it back together, and your device’s video chip does the decoding and encoding at many times real time. Where it is not, the engine’s own software codecs step in, slower but everywhere. The file card tells you which path is in use: hardware, browser software or ClipHeron software.

Neither path uses FFmpeg, and nothing is fetched from a codec CDN. Every byte of code that touches your video is served from this site and listed on the licences page.

Inside a job

Take the compressor. When you drop a video:

1. The file type is read from its first bytes, never from its name. A “.mp4” that is really an MKV is treated as an MKV; a WMV, an image or a PDF is politely refused with a message that says what it is.
2. The container is indexed without reading the whole file. The engine reads small ranges to find the sample tables (or scans a WebM that has none), so a 2 GB file shows its duration, codecs, frame rate and rotation in a second or two and the browser never holds it all in memory.
3. The prediction line is worked out from arithmetic, not a trial run: bitrate × time = size, with the audio subtracted and a resolution step-down when the budget demands it.
4. Frames are decoded, scaled and encoded in a stream, a few at a time, with back-pressure so memory stays bounded. Each frame is released as soon as it has been used. The screen is kept awake, the progress bar shows frames done, and Cancel stops everything within a second.
5. The output is written incrementally to the browser’s private temporary storage, then the index is moved to the front so the MP4 starts playing before it has fully downloaded. The result is handed to the page as a file for the download button and deleted from temporary storage when you download, clear or leave.
6. Nothing hidden rides along. Location, device model, software tags and creation time from the source are not copied into the output unless you tick “Keep creation date”, which re-adds only the date.

The trimmer skips step 4 entirely in lossless mode: it copies the compressed frames you kept into a new container, so no frame is ever decoded. Extracting audio from an AAC source works the same way.

Check it yourself

You don’t have to take our word for any of this. Two quick tests:

Our own automated tests do the same thing on every tool: they record every request the page makes while a reference set of videos is processed and fail the release if anything other than a first-time engine download happens. That test is the reason the privacy line on every tool page is allowed to say what it says.

What ad scripts can and cannot see

ClipHeron is free because the pages carry a small number of labelled ads, served by Google, which load after the tool is ready and never sit next to the drop zone, the progress bar or the download button. Those scripts run in the same page as the tool, and we think you should know exactly what that means.

Your video lives in three places while a job runs: as a file the worker reads, in the worker’s own memory, and as a blob: address that the preview element plays from. The worker’s memory is not reachable from the page at all. The preview’s frames are drawn by the browser, not exposed to scripts. Ads render inside cross-origin iframes, which cannot read the page that contains them. And the tool never writes your file, its name or any frame into the page’s document, into a request, or into an analytics event; events carry only enumerations and buckets such as “10 to 100 MB”.

What we do not claim is that third-party scripts are walled off from the page by the browser. That would require isolating the tool on a separate origin, which we have not done, so our wording is precise: the tool does not give them your files, and the network test proves nothing leaves. The privacy policy spells out what the ad and analytics scripts do collect.

Limits and honesty

Working locally means your device sets the limits. A computer with 8 GB of memory handles 2 GB inputs comfortably and up to 4 GB with a warning; phones are guided to 500 MB and process 4K sources at 1080p output; anything larger is refused before it starts rather than crashing the tab half-way. Software encoding on a phone is slow, and the time estimate says so. HDR becomes standard colour because H.264 cannot carry it. GIFs over a minute are refused because the format cannot make them small.

Some promises we deliberately do not make. We do not accept links to videos elsewhere, because fetching them would break the no-upload rule and invite abuse. We do not open protected (DRM) files. We do not promise that an output will be under a target before it is measured; the result card reports the real size, and a second pass runs if the first overshoots. And a compressor cannot add detail a camera did not record: the before/after view exists so you can judge, not so we can claim.

How we test

The engine is exercised against a reference set of real videos: phone footage in H.264 and HEVC, portrait clips with rotation, HDR, browser screen recordings with no duration, MKV, fragmented MP4, variable frame rate, 60 fps and audio-less clips. Lossless paths (trim, remux, AAC copy) must produce byte-identical samples to the source and identical files across browsers. Compression is checked for size and quality against the source with standard metrics, and anything that regresses fails the build. A corpus of deliberately broken files checks that malformed input produces a specific error and never a hung worker or a crashed tab. Layout tests measure the distance between every ad and every control at four screen widths in the empty, running and finished states. Changes are listed in the changelog.