How to Install FFmpeg on Windows

Installing FFmpeg on Windows takes about 30 seconds. Getting Windows to find it is what eats the afternoon. Almost every "ffmpeg is not recognized" thread traces back to the same two PATH mistakes, and both are avoidable.

Quick answer: To install FFmpeg on Windows, run winget install -e --id Gyan.FFmpeg in PowerShell (Windows 10 1809+ or Windows 11), then close and reopen your terminal and run ffmpeg -version. If you'd rather not use a package manager, download the release build from gyan.dev, extract it to C:\ffmpeg, and add C:\ffmpeg\bin (not C:\ffmpeg) to your PATH.

Install FFmpeg on Windows with winget

One command, no ZIP, no manual PATH editing. Open PowerShell and run:

winget install -e --id Gyan.FFmpeg

The -e flag forces an exact ID match so you don't accidentally install a lookalike package. winget downloads the Gyan release build, unpacks it under your user profile, and registers the bin folder on PATH for you.

Then close that PowerShell window and open a new one. This is not optional. Windows hands a process its environment at launch, so the shell you ran winget in still has the old PATH in memory. In the fresh terminal:

ffmpeg -version

You should see a banner like ffmpeg version 7.1-essentials_build-www.gyan.dev followed by the configuration flags and library versions. If you see that, you're done.

winget ships as part of App Installer on Windows 10 version 1809 and later, and it's preinstalled on Windows 11. On anything older, skip to the manual route below.

To upgrade later: winget upgrade Gyan.FFmpeg. To remove it: winget uninstall Gyan.FFmpeg.

The manual route: gyan.dev ZIP plus PATH

Use this if you're on an older Windows build, on a locked-down corporate machine where winget is blocked, or if you want a specific build variant. It's four steps and the only tricky part is the third one.

1. Pick the right build

FFmpeg.org doesn't publish Windows binaries itself. It links to third-party builders. The two everyone actually uses:

From gyan.dev, you'll see ffmpeg-release-essentials.zip and ffmpeg-release-full.zip. Essentials covers what 95% of people need: x264, x265, libvpx, AAC, MP3, WebP, and the standard filter set. Full adds extras like frei0r plugins, additional audio codecs, and more exotic filters. Take essentials unless a specific filter you need is missing, then step up. The three binaries unpack to a few hundred MB because each one is statically linked.

The -shared builds are for developers linking against libavcodec in C. If you just want the ffmpeg command, they're the wrong download.

2. Extract it somewhere permanent

Unzip to C:\ffmpeg. You'll end up with C:\ffmpeg\bin\ffmpeg.exe, ffprobe.exe, and ffplay.exe.

Don't leave it in Downloads. Don't put it in a OneDrive-synced folder either, since OneDrive's on-demand file placeholders can make the exe temporarily unavailable and produce errors that look nothing like a path problem.

3. Add `C:\ffmpeg\bin` to PATH

Press Win, type "environment variables", open Edit the system environment variables, click Environment Variables, select Path under User variables, click Edit, then New, and paste:

C:\ffmpeg\bin

That trailing \bin is the whole ballgame. PATH holds directories that contain executables, not the folder above them. C:\ffmpeg contains a folder named bin, not a file named ffmpeg.exe, so Windows finds nothing.

4. Verify

New terminal, then:

where.exe ffmpeg
ffmpeg -version
ffprobe -version

where.exe ffmpeg prints the resolved path. If it prints nothing, PATH is wrong. If it prints two paths, you have two installs fighting and the first one wins.

winget vs Chocolatey vs Scoop vs manual

Chocolatey and Scoop both need admin (Choco) or a one-time bootstrap (Scoop) before you can use them. If you're installing FFmpeg once on one laptop, winget or the ZIP is less setup.

PATH mistakes that break FFmpeg on Windows

These four account for most "I installed it and it still doesn't work" reports.

Adding C:\ffmpeg instead of C:\ffmpeg\bin. Covered above, and it's the number one cause. where.exe ffmpeg returning nothing confirms it.

Not opening a new terminal. PATH changes only apply to processes started after the change. Your open PowerShell, your open VS Code, your open Command Prompt all still hold the old copy. VS Code is the sneaky one: its integrated terminal inherits from the VS Code process, so you have to restart the whole editor, not just the terminal panel.

Using setx PATH "%PATH%;C:\ffmpeg\bin". This looks clever and quietly damages your environment. %PATH% expands to the merged user plus system PATH, so you write the entire system PATH into your user PATH. setx also truncates anything past 1024 characters. Use the GUI editor, or in PowerShell target the user scope specifically:

[Environment]::SetEnvironmentVariable(
  "Path",
  [Environment]::GetEnvironmentVariable("Path", "User") + ";C:\ffmpeg\bin",
  "User"
)

Editing the wrong PATH. System PATH applies to every user and needs admin. User PATH applies to you and doesn't. If you edited System PATH but your terminal runs elevated under a different account, or vice versa, the entry won't resolve. To see what your current shell actually has:

$env:Path -split ';'

Windows quirks the install guides skip

Once ffmpeg -version works, Windows has a few of its own edges.

Backslashes in filter arguments. Filter graphs use : and , as separators, so a Windows path inside a filter needs escaping. The drawtext filter is the classic offender:

ffmpeg -i in.mp4 -vf "drawtext=fontfile='C\:/Windows/Fonts/arial.ttf':text='Hello':x=50:y=50" out.mp4

Note the escaped colon and the forward slashes. Plain C:\Windows\Fonts\arial.ttf throws a parse error. There's more on filter syntax in the FFmpeg drawtext filter guide.

PowerShell quoting. PowerShell treats " differently than cmd.exe. Single-quote filter strings when you can, and if a command works in Command Prompt but not PowerShell, quoting is the first thing to check.

Long paths. Windows still caps paths at 260 characters unless long path support is enabled. Deeply nested output folders produce a bare "No such file or directory" that has nothing to do with the file missing.

WSL is an option, not a fix. sudo apt install ffmpeg inside WSL2 gets you FFmpeg, but files live in a Linux filesystem and cross-boundary I/O through /mnt/c/ is measurably slower for large video files. Fine for occasional work, bad for a batch job.

Before you process anything, inspect the file with ffprobe. Half the "FFmpeg produced a broken output" cases are actually a source file that was never what you thought it was.

When the local install stops being the answer

A working ffmpeg on your Windows machine is a local tool on one machine. It doesn't come with you.

The moment the work moves off your laptop, the install problem starts over in a worse form. A Windows Server box needs the binary and a PATH entry managed by whoever owns that server. A GitHub Actions runner needs a setup step on every job. An n8n instance running in Docker needs a custom image. AWS Lambda needs a layer, and the FFmpeg binary is large enough that layer size becomes a real constraint. A Vercel or Cloudflare Workers deployment can't run it at all, because there's no persistent filesystem to put it on.

That's where an HTTP call replaces the install entirely. FFmpeg Micro exposes the same operations as a REST API: submit a job, poll or take a webhook, download the output. No binaries, no versions, no PATH, no servers to run. The request shape looks like this, with the current parameter schema in the docs:

curl -X POST https://api.ffmpeg-micro.com/v1/jobs \
  -H "Authorization: Bearer $FFMPEG_MICRO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "input_url": "https://example.com/source.mp4",
    "operation": "transcode",
    "options": { "resolution": "1080p", "format": "mp4" }
  }'

Same job, callable from Node, Python, n8n, Make, Zapier, or an AI agent through the MCP server. If you want the full arithmetic on when self-hosting is still cheaper, we ran the numbers in FFmpeg in the cloud vs running FFmpeg yourself.

To be clear: for local one-off work on your own machine, the local install is the right call. Install it, learn the flags, use it. The API earns its place when the same operation has to run somewhere you don't control.

FAQ

Why does Windows say 'ffmpeg' is not recognized after I installed it?

Almost always PATH. Either you added C:\ffmpeg instead of C:\ffmpeg\bin, or you didn't open a new terminal after editing PATH. Run where.exe ffmpeg in a fresh PowerShell window: empty output means PATH is wrong, and a printed path means FFmpeg is found and the error is coming from somewhere else.

Which FFmpeg build should I download for Windows?

Take ffmpeg-release-essentials.zip from gyan.dev. It includes x264, x265, libvpx, AAC, and the standard filters, which covers nearly every common task. Only move to the full build if a specific filter or codec you need is missing, and skip the -shared builds unless you're linking against the libraries in C.

Do I need FFmpeg installed to use it from Python or Node?

Yes, if you're using a wrapper. Libraries like fluent-ffmpeg, ffmpeg-python, and moviepy shell out to the ffmpeg binary, so the binary has to exist on PATH or be pointed at explicitly. Packages like ffmpeg-static bundle a binary instead, and a hosted API removes the requirement entirely.

How do I update FFmpeg on Windows?

If you installed with winget, run winget upgrade Gyan.FFmpeg. With Chocolatey it's choco upgrade ffmpeg-full, and with Scoop it's scoop update ffmpeg. For a manual install, download the new ZIP and replace the contents of C:\ffmpeg, leaving your PATH entry alone.

Can I run FFmpeg in Windows CI or on a server?

You can, but you're now installing FFmpeg on every runner or box, pinning its version, and owning the disk and memory it needs. On GitHub Actions that means a setup step in every workflow, which we covered in using FFmpeg in GitHub Actions. An API call has no install step and no version drift.

Want to test an FFmpeg operation before you install anything at all? Try it in the playground, then sign up free when you're ready to wire it into a workflow.