"VLC Convert/Save not working" is really two separate failures: the transcode refuses to run, or it appears to finish and hands you a file that is silent or unplayable. They have different causes, and VideoLAN's own wiki names both — including one it blames on a GUI option rather than on the conversion dialog.
One disclosure first. VideoLAN's Transcode wiki page — the source for most of what follows — carries a banner at the top, verbatim: "This page is outdated and information might be incorrect." So treat it as the official account of the mechanism, and confirm exact option names against your own build with vlc -H.
What Convert/Save actually is
Understanding this one sentence explains most of the weird behaviour. VideoLAN's wiki puts it plainly:
"In VLC, transcoding is exactly the same as streaming across a network, except that the output is sent to a file instead of a network."
That is why the conversion dialog looks like a streaming panel, why an entry called "Streaming" shows up in your playlist while it runs, and why every relevant option is named --sout-something. Convert/Save is not a separate converter bolted onto VLC. It is the streaming engine with the destination pointed at your disk.
The same page sets two expectations up front: the original file stays where it is, so you need room on disk for the copy, and you "should also have a reasonably fast computer, as transcoding can be very slow." VideoLAN's streaming guide calls it "a very CPU-intensive task."
The fastest fix: switch looping off
This is the cause almost nobody mentions, and it is sitting in the official docs. In the Windows section of the Transcode page, verbatim:
"(Note: without the options --no-repeat --no-loop, you may find that loop options selected in the GUI cause transcodes to fail.)"
Read the conditional carefully — it says you may find this, not that it always happens. The wiki gives the symptom and the workaround; it does not explain the mechanism, and no other official page does either.
What to do: make sure no loop option is selected in the GUI before you start the transcode — that is the exact condition VideoLAN names. On the command line, pass --no-repeat --no-loop explicitly, as the note recommends. It costs nothing to rule out, which is why it belongs first.
Try it right here
Runs in your browser. Your file is not uploaded anywhere.
If you only need a straightforward container change and would rather not debug VLC's streaming engine, the converter above does that job in your browser tab — the file is processed locally and never uploaded. Same tool standalone: WebM to MP4; the rest are at all Clapr tools.
Other causes, in order of likelihood
1. The container and the codec do not fit together — and VLC does not tell you. This is the official explanation for "it converted, but the file is broken or silent":
"If you choose an incompatible stream for a given muxer, it may silently fail. You can look for error messages in the messages window to help you debug the failures."
That phrase — it may silently fail — is the honest answer to "why is there no error?" The per-container codec whitelists are narrower than people expect. VideoLAN says of the MPEG-PS muxer: "Supported codecs are MPEG 1/2 and MJPEG for video, MPEG audio and a52 for audio streams." Of the multipart JPEG muxer, flatly: "No sound track can be muxed in such streams."
The docs point at a "streaming features compatibility matrix" for the full mapping, but that page returned "There is currently no text in this page." when checked on 16 September 2026. VideoLAN's transcode module page explains why a static table is hard to keep anyway: "Since supported codecs are dynamically assigned by the running program, sout-transcode-venc, sout-transcode-aenc and sout-transcode-senc have been left blank." Run vlc -H and read what your build exposes.
2. You are writing AVI. VideoLAN states it outright: "The avi muxer in VLC is known to produce corrupt files." If your output is AVI and it will not play, that is a documented defect rather than your settings. Choose a different container.
3. You are on macOS and it crashes. Verbatim: "If you are running VLC on macOS, you should change vlc to vlc -I dummy to avoid possible Bus error problems." And when that workaround misfires: "If the -I dummy option spawns an extra command prompt with error-message vbv buffer overflow you may try -I rc instead, which would ordinarily open a text interface but – under Windows – behaves exactly like the dummy interface." Note the qualifier: the "behaves exactly like dummy" claim is made about Windows.
4. Your Windows path has backslashes in it. Also from the official notes: "due to command line parsing, at times, especially within single and double quote blocks, a backslash may have to be escaped by using a double backslash so that a filename would be D:\path\to\file.mpg". A path VLC cannot parse produces a job that goes nowhere.
5. You set a width and height. VideoLAN is unusually blunt here: "Avoid using width and height parameters, also maxwidth and maxheight! These are applied before the vfilter and might result in unwanted results." If your output came out the wrong shape or size, that is the documented reason.
6. You did not need to transcode at all. VideoLAN: "If your input streams already matches the encoding that you desire for your output stream, then you don't have to transcode at all." The wiki ties this to a GUI option, though its own author hedged — the text reads "In the GUI this is called "keep the original track" (I think)." Hedge and all, it is the fastest path when it applies, because nothing is re-encoded. See keeping the original track in VLC for when that applies.
How to tell it worked
Do not convert a 90-minute file to find out. VideoLAN recommends a sample run, verbatim:
"Transcoding takes quite a while, so it's advisable to use an option like --stop-time=30 to only encode the first 30 seconds—this means you can check the file has transcoded correctly, and that the output is of a suitable quality. (Note: On macOS this trick doesn't seem to work. Just press Ctrl-C after a while, VLC will properly write out the already transcoded segment)."
Check the sample for three things: it plays, it has an audio track, and the duration is what you asked for. If any of those fail, open Tools → Messages — the debugging entry point the docs name, and where a "silent" muxer failure stops being silent.
One quality check while you are there: VLC's transcode module documents a default audio bitrate of 96, in kbit/s. If the output sounds worse than the original, that default is the first suspect. The same module caps sample rate at [0 .. 48000], with the official note "(11250, 22500, 44100 or 48000)" — so a higher-rate source gets brought down. Verify both against your own build; that page lists no version range.
FAQ
Why does VLC say the conversion finished but the file won't play? Most likely you picked a codec the chosen container cannot hold. VideoLAN says that when you "choose an incompatible stream for a given muxer, it may silently fail" — no dialog, just a bad file. Open Tools → Messages. If the output was AVI, note that VideoLAN says its AVI muxer "is known to produce corrupt files."
Why is there no audio in the converted file? Same mechanism — covered in full in VLC converted my video with no audio. Each container in VideoLAN's muxer list accepts only a short list of audio codecs, and one of them, the multipart JPEG muxer, accepts none at all: "No sound track can be muxed in such streams."
Why does VLC's Convert/Save hang or never finish?
Two documented possibilities. VideoLAN warns that loop options selected in the GUI can cause transcodes to fail without --no-repeat --no-loop, so switch looping off first. Otherwise it may simply be slow — the docs call transcoding "a very CPU-intensive task" and advise having "a reasonably fast computer."
Where does VLC show the real error?
Tools → Messages. It is the only debugging entry point VideoLAN's Transcode wiki page names for failed transcodes: "You can look for error messages in the messages window to help you debug the failures." No official VideoLAN article explains a generic "transcoding failed" message beyond that.
Is there a file size or length limit on VLC conversions? VideoLAN's documentation does not state one. The only requirement it spells out is disk space for the second copy, since the original stays put. For a definitive answer, check the official documentation rather than a number quoted on a forum.
Which output formats can VLC write?
The official muxer list covers ts, ps, mpeg1, ogg, asf, asfh, avi and mpjpeg — but not MP4 or MKV, even though official examples elsewhere on the wiki use mux="mp4". That list is incomplete, not a statement of capability. Run vlc -H for your build's real enumeration.
More conversion troubleshooting lives in the fix guides, including VLC's --sout command line for anyone who would rather skip the dialog entirely. If you just want the file converted without a desktop app in the way, start with the browser tools.
Facts cited from VideoLAN's official wiki (Transcode, Documentation:Streaming HowTo, Documentation:Modules/transcode), checked 16 September 2026. The Transcode page carries its own notice that it "is outdated and information might be incorrect" — verify option names against vlc -H for your version.
