ویڈیو کنورٹر

Why a format can appear greyed out

Rather than offering a fixed list of outputs, the [msm_tool slug="video-converter"] tests each format against the browser it is running in before offering it, because codec support depends on the browser, the operating system and sometimes the graphics drivers underneath both. A format the browser cannot actually write is shown as unavailable up front, rather than being offered and failing only after a long encode has already run.

MP4 or WebM, and when each is the right call

MP4 with H.264 is the format every device, browser and upload form expects, which makes it the default answer whenever there is no specific reason to choose otherwise. WebM with VP9 produces a meaningfully smaller file at the same visual quality, worth it for anything destined for a web page rather than an upload form. WebM carries a second advantage that has nothing to do with size: its audio codec is Opus rather than AAC, and Opus is the only route to a video with sound on Firefox or on desktop Linux, neither of which can encode AAC at all.

Converting cannot undo a previous encode

Every pass here decodes whatever is actually in the file and encodes it again from scratch, so any artefacts already baked into the source are preserved rather than cleaned up along the way. Converting is worth doing once, from the best copy available — running a file through repeated conversions adds a fresh generation of encoding loss each time rather than improving anything.

What it cannot even open

MKV, AVI and ProRes files will not load at all, and that has nothing to do with this particular tool: browsers cannot decode those containers, so nothing running in one can read them in the first place. Every video tool on the site shares that same limit on what can come in, regardless of what it is asked to do with the file afterwards.

Why the result can end up larger than the original

A file that was already efficiently encoded has little redundancy left to remove, and re-encoding it spends bits faithfully reproducing the artefacts of that earlier pass rather than shrinking anything. That shows up most with a source that has already been compressed for the web once — converting it again is not guaranteed to make it smaller, and sometimes does the opposite.

When converting is pure loss

If the file already plays where it is headed — the platform accepts the current format, the sound already works on the browser in question — converting it adds a generation of encoding loss for no benefit at all. The reason to convert is a real constraint: a format the destination refuses, or audio that will not encode in the format currently in hand. Absent one of those, the existing file is already the better one to send.