DEV Community: Technorology

Removing an Audio Track From a Video Without Re-Encoding

Technorology — Sun, 27 Sep 2026 21:14:01 +0000

If you have a video file and you want the same video without sound, the correct operation is not a re-encode. It is a container-level track drop. The video stream stays byte-for-byte identical, the audio stream is discarded, and the operation runs at disk speed.

Most "mute video" tools re-encode the video anyway. That is slower and lossy, and it is unnecessary for any MP4, MOV, MKV, or similar container. Here is what the operation actually looks like.

The core idea

A modern video container holds streams. An MP4 might carry a video stream, a stereo audio stream, and a metadata track. Each stream is independent inside the container; the container's moov atom (or Matroska equivalent) references each one separately.

Removing audio means:

Read the container's stream table.
Skip the audio streams when writing the output.
Copy the video stream's samples through unchanged.
Write a new container with only the video stream registered.

Nothing decodes. Nothing re-encodes. The output video is bit-identical to the input at the sample level.

The ffmpeg one-liner

On the command line:

ffmpeg -i input.mp4 -c copy -an output.mp4

-c copy copies every stream through without re-encoding, and -an drops the audio. Runs at whatever your disk can read and write; for a two-hour movie on an SSD, about ten seconds.

The common mistake is dropping the -c copy flag. Without it, ffmpeg defaults to re-encoding, which takes minutes and loses quality:

# Wrong: takes 30 minutes for a movie and produces a worse file
ffmpeg -i input.mp4 -an output.mp4

The browser equivalent

ffmpeg-wasm ships the same behavior for browser use:

import { FFmpeg } from '@ffmpeg/ffmpeg';
import { fetchFile } from '@ffmpeg/util';

const ffmpeg = new FFmpeg();
await ffmpeg.load();
await ffmpeg.writeFile('input.mp4', await fetchFile(inputFile));
await ffmpeg.exec(['-i', 'input.mp4', '-c', 'copy', '-an', 'output.mp4']);
const data = await ffmpeg.readFile('output.mp4');

Same flags, same behavior. Runs entirely in the tab through WebAssembly, so the video never leaves the machine. On a modern laptop the operation is bounded by disk IO, not CPU, so it finishes in seconds.

What does not work

Some tools try to mute by setting the audio track's volume to zero, or by writing silence over the audio samples. Both are wasteful: the audio track is still in the file, it still takes up space, and any player will still allocate a decode buffer for it. Muting is not the same as removing.

Some tools decode the audio to silence and re-encode it. Same problem: the file still has an audio track that is doing nothing.

The right operation is a proper track drop at the container level.

When you cannot use `-c copy`

If your source is a live stream (HLS, RTMP) or a partial file, -c copy may need the container's index to be fully written before it can copy through. In that case, either wait for the recording to finish, or accept a real re-encode for the muted output.

If you need to remove audio from only part of the video (mute the first ten seconds, keep audio for the rest), that is a re-encode of the whole file. There is no way to selectively drop samples without re-encoding.

The one-click version

If you do not want to install ffmpeg locally, Wave's remove-audio-from-video tool does the same operation in the browser. Drop the video, download an MP4 without the audio track. The file stays on your machine, and the operation is a real track drop, not a re-encode.

Summary

Removing audio from a video is a container operation, not a codec operation. Use -c copy -an on the command line or the browser tool that runs the same flags. Any tool that takes minutes to do this is doing the wrong operation, and the output will be worse than the input for no reason.

Doing PDF Redaction Right: Why a Black Rectangle Is Not Enough

Technorology — Sun, 27 Sep 2026 21:11:40 +0000

If you have ever received a "redacted" PDF where the sensitive text is behind a black rectangle, and you copied it out anyway, you already know the problem. Drawing a shape over text does not remove the text. The bytes are still in the file. Ctrl+F still finds them. Copy and paste still pastes them.

Doing redaction correctly is not hard, but the two common approaches (annotation overlays and text replacement) both have failure modes worth understanding before you ship a tool or trust an output.

The three approaches

1. Draw a black rectangle (do not do this)

This is what most quick tools and most home-grown scripts do. They add an annotation or a drawing object on top of the page at the coordinates of the sensitive text. Visually it looks redacted. The text objects underneath are untouched.

Extracting is trivial:

import { getDocument } from 'pdfjs-dist';
const pdf = await getDocument('redacted.pdf').promise;
const page = await pdf.getPage(1);
const textContent = await page.getTextContent();
console.log(textContent.items.map(i => i.str).join(' '));
// prints the "redacted" text

Every PDF library on earth will do this. So will Preview, so will Acrobat's built-in text selection, so will Ctrl+A / Ctrl+C. If your redacted PDF failed this test, it was decorative, not real.

2. Text substitution (better, still fragile)

Some tools locate the target text in the content stream and replace those bytes with an equal number of "X" characters or spaces. Ctrl+F now fails, and copy-paste returns garbage. This is closer to real redaction, but it has three failure modes:

Kerning tables leak the original. If the target was "SSN 123-45-6789" and it is replaced with 15 X's, the character widths of the original are still baked into the Tj operator's positioning. A determined reader can reconstruct the original text from the width sequence.
Ligatures and non-ASCII. Text runs that used a ligature (fi, ffi) or non-Latin characters may not be substitutable byte-for-byte, and the tool either fails silently or corrupts the page.
XObject forms and referenced content. If the sensitive text lives in a shared XObject that appears on multiple pages, replacing it on one page corrupts the others.

3. Rasterise, overlay, reflatten (the correct approach)

The reliable method is to render each redacted page to an image, paint the redaction rectangles onto the image, and rebuild the PDF page as an image-only page. The text objects are gone entirely because the page no longer contains text objects; it contains a raster.

const canvas = document.createElement('canvas');
canvas.width = page.width * 2;
canvas.height = page.height * 2;
const ctx = canvas.getContext('2d');
await page.render({ canvasContext: ctx, viewport: page.getViewport({ scale: 2 }) }).promise;
for (const [x, y, w, h] of redactionRects) {
  ctx.fillStyle = 'black';
  ctx.fillRect(x * 2, y * 2, w * 2, h * 2);
}
const dataUrl = canvas.toDataURL('image/png');

The output is bigger (an image instead of vector text) and it loses accessibility (screen readers cannot read the raster), but the text is genuinely gone. Optionally you can OCR the flattened page to add a searchable text layer that contains only the non-redacted content.

The compliance check

Open the redacted file in a fresh reader.
Ctrl+A, then Ctrl+C.
Paste into a plain text editor.
Search for any of the redacted terms.

If any redacted term appears, the redaction is decorative. If none appears, the redaction is real.

What I use

I moved to PDFslime's redaction tool because it defaults to the rasterise-and-flatten approach, warns you if you try the annotation-only mode, and runs the whole operation in the browser so the sensitive source never touches a server. The tool also runs the paste test on the output automatically and refuses to hand back a file that fails.

If you build a tool that does redaction, please default to the flattening approach. Users assume redaction is safe; if your default is unsafe you will ship a leaked contract for someone.

What flatten redaction cannot fix

Embedded images that contain the sensitive information. If page 3 has a photograph of a driver license, redacting the OCR text on page 3 does not touch the image. You have to redact the image itself before adding it to the PDF, or rasterise the page and paint over the image region in the raster.

And metadata. A PDF's Info dictionary and XMP packet often contain the author's name and previous document title, neither of which any page-level redaction can touch. Strip metadata separately.

Summary

annotation overlay (broken) < byte substitution (leaky) < rasterise-and-flatten (correct). Every "redacted" file worth taking seriously should be built with the last approach and tested with the paste test.

DEV Community: Technorology

Removing an Audio Track From a Video Without Re-Encoding

The core idea

The ffmpeg one-liner

The browser equivalent

What does not work

When you cannot use -c copy

The one-click version

Summary

Doing PDF Redaction Right: Why a Black Rectangle Is Not Enough

The three approaches

1. Draw a black rectangle (do not do this)

2. Text substitution (better, still fragile)

3. Rasterise, overlay, reflatten (the correct approach)

The compliance check

What I use

What flatten redaction cannot fix

Summary

When you cannot use `-c copy`