FFmpeg Online: Browser Tools vs API (Honest Comparison)

You need FFmpeg but don't want to install it

Maybe you're on a locked-down work laptop. Maybe you're on a Chromebook. Maybe you just need to convert one file and installing a command-line tool feels like overkill.

So you search "ffmpeg online" and find a handful of browser tools that promise to run FFmpeg right in your browser tab. No install, no terminal, no fuss.

Some of them work. For small files and simple commands, they're fine. But try to process anything over a few hundred megabytes, or run more than one job at a time, and you hit walls that no amount of JavaScript can fix. Browsers have hard limits on memory, threading, and GPU access. Those limits aren't going away.

This post breaks down the three ways to use FFmpeg without installing it: browser-based WASM tools, server-side online converters, and REST APIs. Each has a different ceiling, and the right choice depends on whether you're converting one file or building a pipeline.

How browser-based FFmpeg tools work

The browser tools you find when searching "ffmpeg online" almost all use ffmpeg.wasm. This is FFmpeg compiled to WebAssembly using Emscripten, so it runs directly in your browser. No server involved. Your files never leave your machine.

That last part matters. If you're working with sensitive footage or client files, knowing that nothing gets uploaded is a real advantage. Processing happens entirely in your browser's sandbox.

The current stable version is ffmpeg.wasm 0.12.x (based on FFmpeg 5.1). It's maintained as an open-source project on GitHub with ~17,000 stars, so the tooling is actively developed and reasonably well documented.

Here's what a typical session looks like on a tool like OnlineFFmpegRunner:

1. Upload a file through the browser

2. Type your FFmpeg command (same syntax as the command line)

3. Wait for processing

4. Download the output

The commands are identical to what you'd run locally:

# Convert MOV to MP4
ffmpeg -i input.mov -c:v libx264 -crf 23 output.mp4

# Extract audio
ffmpeg -i input.mp4 -vn -c:a libmp3lame output.mp3

# Trim a clip
ffmpeg -i input.mp4 -ss 00:00:03 -to 00:00:10 -c copy output.mp4

# Scale down
ffmpeg -i input.mov -vf scale=1280:-2 output.mp4

If you already know FFmpeg syntax, these tools feel familiar. If you don't, the FFmpeg command line guide covers the basics. The cheat sheet has 50 ready-to-use commands.

The limits of running FFmpeg in a browser

Here's where the picture gets less rosy. WebAssembly in a browser tab has constraints that native FFmpeg doesn't, and several of them are fundamental to how browsers work.

Hard memory ceiling at 2GB. This isn't a soft limit you can configure around. WebAssembly memory is backed by an ArrayBuffer, which maxes out at 2GB in most browsers (the spec allows 4GB, but in practice Chrome and Firefox hit allocation failures above 2GB). Your input file, output file, and FFmpeg's working memory all share that space. A 700MB input video that produces a 500MB output with FFmpeg needing workspace on top of that? You're already pushing the boundary. Try a 1.5GB file and you'll likely see this in the console:

RangeError: Array buffer allocation failed

Or the tab just dies silently. There's an open discussion on the ffmpeg.wasm repo about this exact issue, and the answer is: there's no good workaround within the browser.

Single-threaded processing. Native FFmpeg uses multiple CPU threads by default. The WASM version runs single-threaded in most implementations. A multi-threaded build exists, but it requires SharedArrayBuffer, which only works when the page sends specific HTTP headers:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Most free online tools skip multi-threading to avoid these header requirements. The result: a conversion that takes 2 minutes locally might take 8-10 minutes in the browser. H.264 and H.265 encoding feel the difference most.

No hardware acceleration. On your machine, FFmpeg can use your GPU through NVENC, VideoToolbox, or VAAPI. In the browser, you get CPU-only processing. WebAssembly has no path to GPU compute. For encoding-heavy work, the performance gap between WASM and a properly configured server with GPU acceleration is 10-20x.

Limited codec support. The ffmpeg.wasm build includes libx264, libx265, libvpx (VP8/VP9), libmp3lame, vorbis, opus, libwebp, and a few others. That covers common cases. But if you need ProRes, DNxHR, AV1 (via SVT-AV1), or hardware-accelerated encoders, they won't be there. The formats reference has a full breakdown of which codecs serve which purpose, so you can check whether WASM covers your needs.

No filter_complex support in some builds. Complex filter graphs (picture-in-picture, multi-input overlays, watermarks) may fail or behave unpredictably in WASM builds. The filter implementation is incomplete compared to native FFmpeg.

One file at a time, manually. You upload a file, run a command, download the result, and repeat. No batch mode, no scripting, no way to process a folder of files overnight. If you have 50 videos to convert, you're clicking through 50 times.

Server-side online tools: the privacy tradeoff

Some "FFmpeg online" tools take a different approach. Instead of running WASM in your browser, they upload your file to their server, process it with real FFmpeg, and send back the result. FreeTool Online works this way.

The upside: no browser memory limits. The server has more CPU power, more RAM, and a full FFmpeg build with all codecs. Processing is faster and more reliable.

The downside: your file goes to someone else's server. The tool might claim "files are deleted after processing," but you're taking that on trust. For personal projects, probably fine. For client work, medical footage, or anything covered by an NDA, that's a harder sell.

And you still have the manual workflow problem. Upload, wait, download, repeat. No API. No automation. No webhooks. No way to integrate this into an application.

When browser tools are the right call

Browser tools solve a real problem for a specific situation:

• You need to convert one file, right now, and don't want to install anything

• The file is under 500MB (leaving room for output and working memory within the 2GB limit)

• You want a quick format conversion, trim, or audio extraction

• Privacy matters and you don't want to upload to a server

• You're testing an FFmpeg command before using it in a Python script or Node.js app

For these cases, opening a browser tab and running a command is the fastest path. No signup, no API key, no billing. Paste the command and go.

Where browser tools fall apart

The problems start when your needs grow past one-off conversions:

Batch processing. You have 200 product videos that need resizing for TikTok. One-by-one in a browser tab isn't realistic. You need something scriptable.

Large files. Any file over 1-2GB will fail with an ArrayBuffer allocation error or crash the tab. Production video from cameras shoots 4K at hundreds of megabytes per minute. A 30-minute screen recording at 1080p can easily hit 1.5GB.

Automation. You need video processing as part of a pipeline — a user uploads to your app, you need to transcode, generate a thumbnail, and create a preview clip. Browser tools can't be called from code.

Reliability. The browser tab might crash. The page might go down. There's no retry logic, no job queue, no error handling beyond "it didn't work."

Speed. CPU-only, single-threaded, no hardware acceleration. For encoding-heavy work, the performance gap between WASM and a server is 5-10x at minimum.

FFmpeg online via API: the production option

An FFmpeg API takes the "FFmpeg online" concept and makes it programmable. You send an HTTP request with your FFmpeg command. The API runs it on cloud infrastructure with full codec support, hardware acceleration, and no file size limits. You get the output back via URL or webhook.

Here's a real request to RenderIO's API:

curl -X POST https://api.renderio.dev/api/v1/run-ffmpeg-command \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: ffsk_your_api_key" \
  -d '{
    "input_files": {
      "in_video": "https://storage.example.com/raw-video.mov"
    },
    "output_files": {
      "out_result": "output.mp4"
    },
    "ffmpeg_command": "-i {{in_video}} -c:v libx264 -crf 23 -preset fast {{out_result}}"
  }'

The API downloads your input, runs the command, stores the output, and returns a URL. You can poll for the result or set up a webhook to get notified when it's done. It's the same FFmpeg as a service model used by teams that need video processing without managing servers.

What changes compared to browser tools:

• No file size limit. The API streams inputs from URLs. A 10GB file works the same as a 10MB file.

• Full codec support. Whatever FFmpeg supports natively, the API supports. ProRes, DNxHR, AV1, everything. Check the formats reference for codec details.

• Server-grade processing. Commands run on cloud infrastructure with full FFmpeg 7.x and multi-threaded encoding. What takes 10 minutes single-threaded in a browser finishes in a fraction of that on a server. For GPU-accelerated encoding, see the NVENC guide.

• Batch processing. Fire off 200 API calls from a script. Each one runs independently. Process an entire folder in parallel.

• Webhooks. Get notified when processing finishes. No polling, no watching progress bars.

• Integration. Connect it to n8n, Zapier, or call it from your own app code in Python or Node.js.

The tradeoff: it costs money. Browser tools are free. An API charges per command. For a single file conversion, a browser tool wins on price (free beats anything). For anything beyond that, the time you save pays for itself. You can get an API key in about 30 seconds if you want to test it. See the pricing comparison for exact numbers at every volume level.

Comparison: browser WASM vs server tools vs API

Building with ffmpeg.wasm in your own app

If you're a developer who wants to add client-side video processing to a web app, ffmpeg.wasm is worth knowing about even with its limitations. Here's a minimal setup using the 0.12.x API:

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

const ffmpeg = new FFmpeg();
await ffmpeg.load();

// Write input file to WASM filesystem
await ffmpeg.writeFile('input.mp4', await fetchFile(videoFile));

// Run the command
await ffmpeg.exec(['-i', 'input.mp4', '-c:v', 'libx264', '-crf', '28', 'output.mp4']);

// Read the output
const data = await ffmpeg.readFile('output.mp4');
const blob = new Blob([data], { type: 'video/mp4' });

This works well for lightweight operations: generating thumbnails, trimming short clips, extracting audio from small files. The user's browser does the work, which saves you server costs.

Notice the CRF value. I bumped it to 28 (lower quality, faster encode) because encoding at CRF 23 in the browser is painfully slow for anything over 30 seconds. The compression guide explains how CRF affects the quality-size tradeoff, but in WASM you'll want to favor speed.

For the multi-threaded version (roughly 2x faster), your page needs these headers:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Without them, you're stuck with the single-threaded build. Some hosting platforms (Vercel, Netlify) make these headers straightforward to configure. Others require more work.

When to offload to an API instead: If your users are uploading files over 200MB, if you need consistent processing times, or if you're doing anything more complex than a basic transcode, send the heavy work to an API and keep client-side processing for previews and thumbnails. The serverless FFmpeg comparison breaks down the options for server-side processing.

The practical decision

Pick based on what you actually need:

Use a browser tool if you're converting a single file under 500MB and just need it done. No account, no setup, no cost. The command line is faster if you can install FFmpeg, but browser tools work when you can't.

Use a server-side tool if the file is too large for WASM and you don't care about automation. Understand that your file goes to their server.

Use an FFmpeg API if you need batch processing, automation, large files, or production reliability. The complete API guide walks through setup, or sign up and try a command to see for yourself. For zero infrastructure, run FFmpeg in the cloud without managing servers. If you're deciding between hosted and self-hosted, the comparison guide has the cost math at every volume level.

Install FFmpeg locally if you're a developer who'll use it regularly. The command line tutorial gets you from zero to working in 10 minutes. Local FFmpeg is the most powerful option when you have terminal access.

Most developers start with browser tools or local FFmpeg, then move to an API once they need to process video from code. Browser tools are a good entry point. They're just not where most workflows end up.

FAQ

Is FFmpeg online safe to use?

Browser-based tools (the WASM kind) are safe because your files never leave your machine. Everything runs in the browser sandbox. Server-side tools are a different story. Your files get uploaded to their servers. Check the tool's privacy policy, but even then you're relying on trust. For sensitive content, stick with browser-based WASM tools or an API provider with documented security practices (RenderIO runs each job in a fully isolated sandbox that's destroyed after processing).

Can I run FFmpeg in the browser on mobile?

Technically yes, but the experience is rough. Mobile browsers have even tighter memory limits than desktop browsers (often 1GB or less for a tab), and mobile CPUs are slower at encoding. A conversion that takes 5 minutes on a desktop browser might take 15-20 minutes on a phone, if it doesn't crash first. For mobile, an API where the processing happens server-side is a much better fit.

What's the maximum file size for FFmpeg in the browser?

The practical limit is around 600MB-1GB for the input file, depending on the operation. WebAssembly memory caps at 2GB total (input + output + working memory). If your input is 800MB and the output is 600MB, you've used 1.4GB before FFmpeg's internal buffers. Complex operations that need more working memory will fail at even smaller input sizes.

Is there an FFmpeg online tool that supports batch processing?

No browser-based tool supports batch processing. You process one file at a time, manually. For batch work, you need either the FFmpeg command line (with shell loops) or an FFmpeg API that you can call programmatically. The API approach lets you submit hundreds of jobs in parallel from a script.

Can FFmpeg WASM do everything the desktop version can?

No. The WASM build lacks GPU acceleration, has limited codec support (no ProRes, no hardware encoders), runs single-threaded by default, and can't handle files over ~2GB. Complex filter graphs may also fail. For the full FFmpeg feature set, you need either a local install or a cloud API that runs native FFmpeg.

How does FFmpeg online compare to HandBrake or other GUI tools?

HandBrake is a desktop app you install locally. It uses FFmpeg under the hood and gives you a graphical interface for common operations. FFmpeg online tools run in the browser with no install required, but they're less capable (memory limits, fewer codecs, slower processing). If you can install software, HandBrake gives you more power. If you can't install anything, browser tools are your option. For production workloads, both fall short of an API.

Do online FFmpeg tools work offline?

The initial page load requires an internet connection (to download the WASM binary, which is 25-30MB). After that, some tools work offline since all processing is local. But most don't cache the WASM binary aggressively enough for reliable offline use. If you need offline FFmpeg, just install it locally.