Removing the Sound From a Video Without Touching the Picture

The one command in this family that decodes nothing

Most video tools have to open the picture to do their job: rotating it, resizing it and compressing it all require decoding every frame, doing something to it, and encoding it again. Removing a sound track requires none of that. The container holds separate streams, and taking one out is a question of rewriting the index and copying the rest across. That is exactly what -c copy -an does: copy every stream that survives selection, and exclude audio from the survivors.

That the picture really is untouched is the sort of claim worth testing rather than believing. Take a test clip, pull the raw H.264 stream out of it, then run the tool's command, pull the raw stream out of the result, and compare. Both came to 391,608 bytes with the identical checksum. Not similar, not visually indistinguishable — the same bytes. Whatever the encoder decided about your footage the day it was made is still exactly what the file says, and nothing this tool did could have changed it.

Muting and removing are not the same thing

There are three states a video can be in, and people use one word for all of them. Muted in a player: the file is unchanged, only your speakers are off. Silenced in the file: the audio track is still there, still occupying its share of the bitrate, but every sample is zero. Removed: there is no audio track, the container lists one fewer stream, and no player can find anything to play. This tool does the third.

The distinction matters in places you would not guess. Publishing platforms that scan uploads for copyrighted music examine the audio stream; a file with no audio stream has nothing to scan, while a file with a silent one is still a file with an audio stream and may still be processed as such. Editing software behaves differently too: a timeline import of a clip with no audio gives you a video-only item, while a silent track gives you a track that has to be dealt with. And a silent track still costs bits, sometimes a surprising number of them, because encoders do not always compress silence to nothing.

The saving is smaller than almost everyone expects

Sound feels like half of a video, so it feels as though removing it ought to halve the file. It does not, because the two are not remotely the same size. A stereo track at 128 kbps carries 16 kilobytes a second. A modest 1080p picture at 2 megabits per second carries 250. The audio is six percent of that file, and on a clip from a modern phone shooting 4K at 45 megabits per second it is well under one percent. The table gives four common cases with the arithmetic done.

The pattern runs the other way from intuition: the better the picture, the less the sound is worth removing. If your reason for muting is to get under an upload limit, this is the wrong tool — you will free up one or two percent and still be over. Compress or trim the video instead, and mute only for the reason muting is actually good for, which is that you do not want the sound in the file.

What survives the copy, and one thing that quietly does not

Because -c copy moves streams rather than recreating them, the output keeps a great deal you might have assumed would go. The container's global metadata comes across: the creation date, the device that recorded it, any title or comment, the encoder string. If any of those name the audio — a title that is a song title, a comment mentioning a recording — they are still in the file after the sound has gone. Removing an audio stream is not the same as removing every trace of it, and if the point of muting was privacy, check the metadata separately.

Subtitles survive too, which is usually what you want. A subtitle track is not audio, so -an does not touch it and -c copy carries it across intact. There is one catch worth knowing about, and it comes from ffmpeg's default behaviour rather than from this tool: with no explicit stream map, ffmpeg selects the best single stream of each type. A file carrying three subtitle tracks or two camera angles therefore comes out with one of each. If your source has multiple tracks of anything, check the result before you throw the original away.

If the button is greyed out and it says there is no sound

Before loading a large encoder just to answer a small question, the tool asks the browser whether the file has a sound track at all. It does that by creating a hidden video element, starting it muted, and reading three properties that different browser engines expose under different names. If all three come back empty it concludes there is no audio, prints a line saying so, and disables the button on the grounds that there is nothing to do.

That check is the tool's weakest link, because those three properties are not equally trustworthy. One is specific to a single engine. Another has to be enabled before it reports anything in the most widely used browser. The third only becomes non-zero once some audio has actually been decoded, which may not have happened by the time the check runs. If the tool tells you a clip has no sound and your ears say otherwise, do not conclude the file is odd: try the same clip in a different browser, where a different one of the three properties is the one that answers. The command itself is not affected — it is the gate in front of it that guessed wrong.

Frequently asked questions

Will the picture change at all?

No, and this is one of the rare cases where that can be stated as a fact rather than an intention. The command contains no filter and no video encoder — -c copy moves the compressed video stream across without decoding it. Pulling the raw stream out of a test clip and out of its muted copy gave the same byte count and the same checksum. Resolution, frame rate, bitrate, colour, keyframe positions: all identical, because none of them was ever looked at.

Why did my file barely get smaller?

Because the sound was never the heavy part. A stereo track at 128 kbit/s uses about a sixteenth of what a modest 1080p picture uses, and about a three-hundredth of what a phone's 4K mode uses. The result line under the download tells you the exact number of bytes that left in your particular case. If the number disappoints you, the tool did nothing wrong — it removed all the audio there was, and the audio was small. To make a video appreciably smaller you have to work on the picture, which means compressing or resizing it, both of which cost quality.

Can I get the sound back afterwards?

Not from the muted file — there is nothing in it to recover, because the track was excluded rather than blanked. You can of course keep your original, and that is the safe habit. If you know in advance that you want the sound as a separate file, run the clip through the audio extractor before muting: that gives you a standalone track alongside the silent video, and you can put the two back together later in any editor. The tool says as much in a line above its button, and it is worth reading before you press it.

How is this different from just turning the volume down before I share it?

Turning the volume down changes nothing in the file: whoever receives it still has the full sound track and can play it. Encoding a track of silence changes the file but leaves an audio stream in it, still occupying bitrate, still visible to anything that inspects the file. Removing the stream changes what the file is: it no longer declares audio at all. Choose the third when the sound must not travel with the video — a recording with a conversation in the background, footage with music you have no licence for, anything you would rather not hand to a stranger.

Does removing the sound also remove everything that mentions it?

No. The audio stream goes, and its own stream-level tags go with it, but the container's global metadata is copied across untouched — creation date, device, title, comment, encoder string. If any of those describe the recording or name a piece of music, they are still there. A subtitle track survives too, since subtitles are not audio. If you are muting for privacy rather than for convenience, treat the metadata as a separate job and inspect the output before sending it anywhere.