How to Fix FFmpeg Not Working in Windows 10 and 11

When ffmpeg is not working on your PC, reinstalling is almost never the fix. In most of the cases I see on support calls, the program is installed perfectly well and the fault sits in one of four places: the PATH variable, a stale copy of ffmpeg shadowing the good one, a terminal window that was open when you changed PATH, or the command itself dying on a codec or a locked file. Each one prints a different message and takes a minute to confirm. This guide runs the checks in the order I would use on a customer machine.

What ffmpeg not working actually looks like

Windows never reports ffmpeg as broken. It reports one of a handful of failures, and the wording tells you which layer gave up.

Check whether ffmpeg is on PATH at all

Open Command Prompt from the Start menu, or press Win+R and type cmd. For PowerShell, press Win+X, choose Terminal, and pick the PowerShell tab.

where ffmpeg

In PowerShell use where.exe ffmpeg, because where on its own is an alias for Where-Object. No output means Windows searched every folder on PATH and found no ffmpeg.exe. Several paths mean more than one copy exists, and the first line wins.

Next, ask the binary to identify itself:

ffmpeg -version

The first line carries the version and build, for example ffmpeg version 7.1.1-full_build-www.gyan.dev Copyright (c) 2000-2025. Underneath sit the configuration line, which lists every library the build was compiled with.

The same folder holds ffprobe, which reads media metadata, and ffmpeg -hide_banner -encoders lists the formats the build can produce.

Cause 1: ffmpeg is not on your PATH

PATH is the ordered list of folders Windows walks when it looks for an executable. If the folder holding ffmpeg.exe is not on that list, the shell cannot find it no matter how cleanly it was installed.

1. Press Win+Pause to open System. On Windows 10, open Control Panel, search for System, and choose Advanced system settings; Windows 11 has the same page in Start search.
2. On the System page choose Advanced under Advanced system settings.
3. Choose Environment Variables at the bottom of the Advanced tab.
4. In the upper box under User variables, select Path and choose Edit. The lower box holds the machine PATH and needs administrator rights; use it only if you installed ffmpeg somewhere shared.
5. Choose New and type the folder that contains ffmpeg.exe, not the exe itself. A manual install puts it in C:\ffmpeg\bin.
6. Choose OK on the Path window, then OK on Environment Variables, then OK on System Properties. Every dialog must be confirmed.
7. Open a new terminal and run ffmpeg -version.

Both package managers work for the install itself. winget install Gyan.FFmpeg and choco install ffmpeg each produce a working copy. A winget install lands in a user folder under C:\Users\yourname\AppData\Local\Microsoft\WinGet\Packages, and a user folder is not automatically added to PATH, so where ffmpeg can come back empty until you add that path yourself. Chocolatey links its executables into C:\ProgramData\chocolatey\bin, which normally sits on the machine PATH already.

Why setx PATH breaks more than it fixes

A lot of answers online tell you to run this in Command Prompt:

setx PATH "%PATH%;C:\ffmpeg\bin"

It works often enough that people keep recommending it, and it has three failure modes that cost real time.

• setx refuses to write a value longer than 1024 characters, and on some builds it does that silently. On a long PATH the new value gets cut, so your entry can vanish along with the entries near the end of the old value.
• In the user scope, %PATH% expands to the combined process PATH, which already contains the machine PATH. Saving that back into the user PATH duplicates every machine entry, and setx stores it as a plain string, so entries written as %SystemRoot%\system32 stop expanding.
• setx writes to the registry for future processes only. It cannot change the shell you are sitting in, and without administrator rights it never touches the machine PATH.

The Environment Variables dialog has none of these problems. It keeps the two scopes separate and it has no length limit. Use the dialog.

Cause 2: an old or wrong copy wins

When where ffmpeg returns more than one path, the first line is the one Windows runs every time. A typical result on a machine that has been upgraded a few times:

C:\Program Files (x86)\ffmpeg\bin\ffmpeg.exe
C:\ffmpeg\bin\ffmpeg.exe

The copy in Program Files (x86) might be from 2016 and might not know about encoders you assume it has. It is also the copy that answers every command you type, which is why the new install seems to have done nothing.

Watch for a different kind of shadowing: a leftover ffmpeg.bat sitting in a folder earlier in PATH than the real executable. A scripts folder, a Scoop shim directory, or even your Documents folder can do it. Command Prompt prefers the batch file because PATHEXT lists .BAT ahead of .EXE.

1. Run the winner by full path to see what it is: "C:\Program Files (x86)\ffmpeg\bin\ffmpeg.exe" -version.
2. Remove the old folder from PATH, or rename the stray batch file so the order stops mattering.
3. Call the copy you want directly. In PowerShell prefix the path with an ampersand: & "C:\ffmpeg\bin\ffmpeg.exe" -version.

Cause 3: the terminal was already open

Changing PATH does not change programs that are already running. Every Command Prompt, every PowerShell tab, the integrated terminal in VS Code, and anything started from File Explorer keeps the environment it was launched with. This fools people most often, because the change was correct and the error is real.

Close the terminal completely and open a new one. With Windows Terminal, close the whole window rather than just the tab, since a new tab inherits the environment of the window process. If you edited the machine PATH, sign out and back in, because Explorer will not see the change until it restarts.

For a quick refresh inside an open PowerShell window, pull the values back out of the registry:

$env:Path = [Environment]::GetEnvironmentVariable('Path','Machine') + ';' + [Environment]::GetEnvironmentVariable('Path','User')

If the command still fails after that, the edit was probably never saved. Click through all three dialogs with OK, then confirm in a brand new window.

Cause 4: the command runs and the job fails

Now the shell finds ffmpeg, starts it, and the failure moves downstream. Two families of error come up most often.

Unknown encoder means the build is wrong

Unknown encoder 'libmp3lame' and Unknown encoder 'aac' are not path problems. They mean the ffmpeg.exe you are running was compiled without that encoder, which happens with old builds and with stripped down builds. Confirm it with:

ffmpeg -hide_banner -encoders | findstr libmp3lame

In PowerShell use ffmpeg -hide_banner -encoders | Select-String libmp3lame. No output means the encoder is missing, and no flag will create it. Replace the build with a full one from gyan.dev or the BtbN builds on GitHub. Decoder errors behave the same way, so Unknown decoder 'hvc1' means the build cannot read HEVC video.

Permission denied means the file or folder is blocked

The full line usually looks like Error opening input file C:\Videos\holiday.mp4: Permission denied. The word input or output tells you which side failed.

• Another program has the file open. VLC, Windows Media Player and the Explorer preview pane all hold a lock while it is in use.
• The file sits in a OneDrive folder that is still syncing, or a download that is still being written.
• The output folder is protected. Writing into C:\Program Files or C:\Windows needs elevation.
• Ransomware protection can block writes. Under Windows Security, Ransomware protection, Manage ransomware protection, Controlled folder access, allow the program rather than switching protection off.

Copying the source into a plain folder such as C:\Videos and running the job again settles most of these in one attempt.

A reset checklist that covers all four causes

1. Run where ffmpeg and write down every path it prints.
2. Run the first path directly, with quotes if it contains spaces, and add -version. A working binary here means the problem is PATH order.
3. Compare the version line with the build you meant to install.
4. Open a brand new terminal window and run ffmpeg -version again.
5. Run ffmpeg -hide_banner -encoders | findstr libmp3lame to confirm the encoders you need exist.
6. Run a real job on a file you can write to: ffmpeg -i "C:\Videos\sample.mp4" -vn -c:a libmp3lame -q:a 2 "C:\Videos\sample.mp3".
7. If steps 5 or 6 fail while step 2 passed, reinstall from a trusted build and start again at step 1.

If you never got as far as installing it, the guide to installing FFmpeg on Windows 11 and adding it to PATH covers a clean setup. Once the binary answers, the MP4 to MP3 conversion walkthrough is a good first job and the video compression guide shrinks files.

Frequently asked questions

Why does Windows say ffmpeg is not recognized as an internal or external command?

Windows searched the folders listed in the PATH variable and found no ffmpeg.exe in any of them. Either ffmpeg is installed in a folder that is not on PATH, or PATH was changed without opening a new terminal. Run where ffmpeg in Command Prompt to see every copy Windows can find, then add the folder that holds ffmpeg.exe to your user PATH and open a fresh window.

Where is the ffmpeg folder on my PC?

It depends on the install method. A manual ZIP install usually ends up at C:\ffmpeg\bin. The winget package lands under C:\Users\yourname\AppData\Local\Microsoft\WinGet\Packages in a folder named after the package. Chocolatey keeps the real files in C:\ProgramData\chocolatey\lib\ffmpeg and links them into C:\ProgramData\chocolatey\bin. The fastest way to find yours is to run where ffmpeg and read the first line.

Should I add ffmpeg to the system PATH or my user PATH?

Use your user PATH unless the install lives in a shared location and other accounts need the same tool. The user PATH is the upper list in the Environment Variables dialog and needs no administrator rights. Editing the machine PATH as a normal user fails, and as an administrator a mistake there affects every account on the machine.

Why does ffmpeg still say not recognized after I restarted the computer?

A restart should clear a stale terminal, so if the error survives it the PATH entry was probably never saved or it was added to the wrong list. Open the Environment Variables dialog again and confirm the path sits in your user variables. On Windows 11 also check Settings, Apps, Advanced app settings, App execution aliases and turn the ffmpeg alias off, because an alias in the WindowsApps folder can shadow a real install.

Is it safe to reinstall ffmpeg over an existing copy?

Reinstalling is safe, and it does not remove a stale copy that sits earlier in your PATH, so it is not the first thing to try. Run where ffmpeg before you install anything. If the path already resolves to a working binary and the error mentions encoders or file access, reinstalling changes nothing. A clean reinstall is worth it when the build is old or when the encoder list comes back empty.

What to remember

• Most ffmpeg problems live in PATH rather than in the program, so diagnose before you reinstall.
• where ffmpeg lists every copy on the machine, and the first path printed is the one that runs.
• Add the bin folder to your user PATH with the Environment Variables dialog rather than with setx.
• Open a new terminal after every PATH change, since running programs keep their old environment.
• Unknown encoder points at the build, and Permission denied points at the file or the folder.
• An empty encoder list means replace the build.

Open Command Prompt, run where ffmpeg, then run ffmpeg -version in a window you opened just now. Those two commands tell you which of the four causes you have and take fifteen seconds. If the output points at a missing install, the Windows 11 install walkthrough covers the clean setup.