What we check before publishing

The work happens on your machine, and what that means

The claim that files are not uploaded is the one thing on this site you should be able to verify yourself, so here is how to do it. Open your browser's developer tools, switch to the network tab, and run a conversion. Loading the page itself fetches what any page fetches, meaning its stylesheet, its script, the web fonts, and one small analytics ping that counts the page view. Then the first conversion pulls down the encoder. After that, nothing outbound carries your video, and there is no upload request to look for, because there is no endpoint on our side that accepts one.

What that buys you is simple: no copy of your footage exists anywhere you do not control, so there is nothing to be logged, retained, scanned, or leaked later. What it costs you is equally simple. Your own device does the encoding, so a long or high-resolution file is limited by your memory and your processor rather than by a server farm. That trade is the whole design, and we would rather state both halves of it than only the flattering one.

Where the encoding behaviour comes from

DivXpress does not invent its own encoder. It runs a WebAssembly build ofFFmpeg in the browser, by way of theffmpeg.wasm project, usingWebAssembly to run compiled code at usable speed inside a page. Everything the tool does is an FFmpeg command with arguments chosen for you.

That means the behaviour we describe is checked against the upstream documentation, not against our own guesswork:

• MP4 and MOV output is H.264 video from x264 with AAC audio. What the quality slider does, and what a CRF value means, follows theFFmpeg H.264 encoding guide.
• WebM output is VP9 video with Opus audio, the pairing defined by theWebM Project.
• GIF output uses the two-pass palette approach, generating a palette from the clip and then applying it, per the palettegen and paletteuse entries in the FFmpeg filters documentation.
• Format and codec support across browsers is checked againstMDN's media documentationrather than against what happened to work on one machine.

Where a guide quotes a number, such as a bitrate range for 1080p, it comes from a published recommendation or from upstream documentation, and the guide says so in the text. What you will never find here is a benchmark table, a stopwatch figure, or a quality score presented as our own measurement. We do not run a test lab, so we do not publish numbers that would imply we do.

What the converter cannot do

Running an encoder inside a browser tab imposes real constraints. These are the ones worth knowing before you start, rather than after a conversion fails:

• It is single-threaded. The build we use does not require the special cross-origin headers that multi-threaded WebAssembly needs, which keeps the tool working everywhere, at the cost of speed. Expect it to be slower than a desktop application on the same file.
• Memory is the ceiling, not file size. There is no hard limit, but the input, the output, and the encoder all live in your browser's memory at once. Past roughly 600 MB the tool warns you, and on a modest device a long 4K clip can fail outright. Trimming before converting is the reliable fix.
• Output codecs are fixed per format. H.264 and AAC for MP4 and MOV, VP9 and Opus for WebM, LAME for MP3. There is no H.265, no AV1, and no ProRes output.
• Unusual input codecs may not decode. The browser build carries a smaller set of decoders than a full desktop FFmpeg. Common camera, phone, and screen recording files are fine. Broadcast, professional, and older proprietary formats sometimes are not, and when a decoder is missing the conversion ends with an error rather than a broken file.
• One file at a time, one video and one audio track. There is no batch queue. Additional audio tracks, subtitle tracks, and chapter data are not carried into the output.
• It converts, it does not edit. There is no cutting or trimming here, no joining two clips, no cropping and no rotating. Where a guide tells you to trim first, it means trimming in whatever recorded or edited the clip, then bringing the shorter file back to this site.
• Nothing is remembered. Close or refresh the tab and the file, the result, and the settings are gone. That is a privacy property, not an oversight, but it does mean there is no history to go back to.

How the guides are kept current

Every guide carries a published date. Once the advice in it has actually been revised it also carries an updated date, and there is a third date, "last checked", for the day the page was last read against its sources without the text needing to change. Those three mean three different things on purpose. The updated date moves when the writing moves and stays put when it does not, so it cannot be used to make an old page look fresh, and you will not see it bumped across the whole guide set on one day.

A guide gets re-read when one of two things happens:

• The converter's own settings change. If the encoder, a default, or a slider range moves, the guides describing it are corrected in the same pass, because a guide that no longer matches the tool is worse than no guide at all.
• Something upstream moves, or a reader writes in to say a claim no longer holds. Codec support in particular ages quickly, and the pages most exposed to that get looked at first.

What we are not going to claim is a review calendar. This is a small project, not a newsroom with a rota, and a promised quarterly sweep that nobody performs would be exactly the kind of decorative process this page exists to avoid.

When a correction changes the advice rather than the wording, we say what changed in the text instead of quietly editing over it. Pages are not deleted to hide a mistake.

Who writes this

Everything here is published under one byline, the DivXpress team. That is a house byline for the site itself, not a person, and we are not going to dress it up as one. You will find no invented author photograph on these pages, no fabricated biography, and no list of credentials, because inventing any of that would be the opposite of the honesty this page is meant to demonstrate.

What stands behind the guides is not a claimed résumé. It is the sourcing described above, the fact that the tool doing the work is a documented open-source encoder anyone can read, and a correction address that reaches a human. Judge the pages on whether they match the upstream documentation and whether the tool behaves as described.

What the site costs to run

Very little, and it is paid out of pocket. A domain registration and static hosting are the entire bill, which is why the tools can be free with no account and no paid tier. You will not find an ad unit, an interstitial, a countdown, or an upsell on any page here.

As the site stands today, every outbound link on it goes to upstream documentation, and you can check that against the sources block at the end of any guide. Should a commercial arrangement ever sit behind a link, it will be labelled at the link rather than explained away in a footer. If the tools ever stop being free, or a future feature needs a server and therefore an upload, this page and theprivacy page will say so before it applies to you, not after.

What we will not do

• Upload, copy, retain, or inspect your files. There is no server on our side that receives them.
• Require an account, an email address, or a sign-up to use any tool.
• Watermark your output or embed anything in it.
• Push a desktop installer, a browser extension, or a bundled download.
• Publish invented ratings, review counts, user numbers, or test results.
• Present a commercial link as an editorial recommendation without labelling it.
• Set tracking cookies or sell data. Analytics here are aggregate page counts with no profile attached.

Telling us a file would not convert

Because the conversion happens on your device, we cannot see what went wrong. No log reaches us, and no copy of your file exists for us to inspect. That makes your description the only evidence there is, so a useful report matters more here than on most sites.

Email [email protected] with as much of this as you can:

• The tool or page you used, and the output format you chose.
• The input format and roughly how large the file was, plus how long the clip runs.
• Your browser and operating system, including whether it was a phone or a computer.
• What appeared on screen: the exact error text, or the point at which the progress bar stopped.

Corrections to a guide go to the same address, and so does anything you think is overstated on this page. Please do not attach the video. We do not need it, we would rather not have it, and a tool built specifically so that files are never uploaded is a poor place to start emailing footage.