Every Converter Here Is Tested by a Robot with Real Files

Online file converters have a trust problem, and everyone who has used one knows it: you search “mkv to mp3”, land on a page that swears it can do exactly that, feed it your file, and watch it fail — or worse, produce a broken file that fails later, somewhere that matters. Sites in this category compete by shipping pages, not working conversions, because pages are what search engines see.

We decided to make that failure mode structurally impossible on ConvertUno: the build fails if any converter page exists without a recorded proof that a real file was converted on that exact page.

The registry

Every conversion page on this site — mkv-to-mp4, heic-to-jpg, all 81 of them — must have an entry in a JSON file called the verified-pairs registry. Entries look like this:

"mkv-to-mp4": {
  "collection": "convert",
  "sample": "sample_640x360.mkv",
  "engine": "webcodecs",
  "remux": true,
  "outputMagic": "mp4/ftyp",
  "outputBytes": 577667,
  "outputHeadHex": "0000001c66747970",
  "durationMs": 468,
  "verified": "2026-08-10"
}

The rule: entries are only ever written by the verification harness, a script that builds the production site, serves it locally, and drives a real Chromium browser through the page exactly like a user — load the page, drop in a real fixture file, click the button, wait for the result. Then it checks three things:

1. The output’s magic bytes. An MP4 must contain an ftyp box, a PNG must start 89 50 4E 47, a FLAC must start fLaC. Not “the page said done” — the actual bytes of the actual output blob.
2. Which engine ran. The result panel exposes a data-engine attribute (hardware WebCodecs path, the wasm fallback, canvas, and so on), so the registry records how the conversion happened, not just that it did. If a future change silently knocks a fast hardware path onto the slow fallback, the recorded engine changes and we see it.
3. Honesty of the result. The remux flag may only be true when every stream that exists in the source was copied without re-encoding — the same rule the UI uses before showing its “lossless” badge.

A pre-build gate then cross-checks every content file against the registry. New page without a proven run? The build refuses to produce a site. There is no code path where a converter page ships unproven.

What building this caught

The satisfying part of verification systems is that they find bugs in two directions: in the product, and in themselves.

The product bug that mattered most: some videos carry audio the browser cannot decode — AC-3 tracks in movie rips are the classic case. Our media library’s conversion API doesn’t throw for those; it silently discards the track. The result: a “successful” conversion that produced a muted video. The harness surfaced the discard behavior while we were generating test fixtures, and the engine now detects any non-intentional track discard and reroutes the file to the fallback engine, which can decode those codecs. A silently muted file is precisely the kind of lie this site exists to not tell.

Our first version of that fix had its own bug: the discard check also triggered on intentional discards — extracting MP3 from a video deliberately throws the video track away — which silently pushed every audio extraction onto the slow fallback path. Re-running the registry caught it within minutes: a pair that had been recorded as an instant lossless copy suddenly re-verified as a slow re-encode on a different engine. That diff is the feature.

The harness lied to itself twice. First: we initially compared magic bytes by decoding blob headers with TextDecoder('latin1') — which is not Latin-1. Browsers alias it to windows-1252, which remaps the 0x80–0x9F range, including 0x89: the first byte of every PNG. Every PNG conversion on the site “failed” verification while working perfectly. The matcher now compares raw hex. Second: the harness originally accepted any blob on the page with a matching signature — but a page that previews your input file creates blobs too, so converting MP4 to M4A could have “verified” by finding the input. Only blobs created after the convert click count now.

The fixtures were half the work

Proving a converter needs a real file in the source format, and some formats resist being obtained honestly:

• FLAC: no browser can encode FLAC, so we wrote a valid FLAC file byte by byte from the spec — frame headers, CRC-8 and CRC-16 checksums, uncompressed VERBATIM subframes — and confirmed the site’s decoder plays it. The fixture tests the site, and the site validated the fixture.
• VOB (DVD video): generated by the site’s own wasm engine encoding real MPEG-2 with MP2 audio — the same binary users’ browsers download, producing a genuine DVD-style stream.
• MTS (AVCHD camcorder): a valid MPEG transport stream repacketized from 188-byte packets to AVCHD’s 192-byte framing, exactly the way cameras write it. Verification then revealed our browser engine reads M2TS natively — so that page honestly advertises an instant, lossless repack, because the registry proved one.
• And a trap: generating container fixtures in Node silently produced video-only files, because the media library discards audio tracks when no audio decoder exists — the same discard behavior above, encountered from the other side. All container fixtures are generated in a real browser now.

What this doesn’t prove

Honesty about the system requires stating its limits. A registry entry proves the pair worked on the recorded date, on the code that was live then — it is a point-in-time proof, not a monitor. Continuous coverage comes from a separate smoke suite that runs real files through every engine dependency against the production site on every deploy. And the registry is plain JSON in a repository: the gate cannot distinguish a real run from a hand-typed entry. It is a discipline made mechanical, not a cryptographic guarantee.

But the discipline holds: 81 pairs, every one backed by a run where a robot picked up a real file, pushed it through the real page, and read the real bytes that came out. If a page exists on this site, the conversion works — because it has to, or the site won’t build.