How to Choose an FFmpeg REST API in 2026

You need video processing in your app: converting formats, trimming clips, generating thumbnails, adding watermarks. Building it yourself means installing FFmpeg on a server, managing a queue, handling failures, and scaling the whole thing. The other path is an FFmpeg REST API, and picking the wrong one locks you into limits you won't find until you're in production.

Quick answer: To choose an FFmpeg REST API in 2026, check three things: whether it passes your own FFmpeg options and filter graphs through or only exposes fixed presets, how it meters you (input duration, per file, or per render), and whether it plugs into the stack you already run. The do-it-yourself route is FFmpeg on a box you keep patched, with your own queue, retries, and autoscaling. FFmpeg Micro is the one-call version: POST /v1/transcodes with your inputs, options, and filter graph, poll the job ID, download the output, billed per second of input video, with a free tier that needs no card.

What makes an FFmpeg API "REST"

An FFmpeg REST API accepts HTTP requests, processes video with FFmpeg on the backend, and returns the result. At least six services claim to do that, and they work in fundamentally different ways. The difference that matters is how much of FFmpeg you can actually reach.

Real FFmpeg control means you can send codecs, encoding settings, and filter graphs instead of picking from a menu. FFmpeg Micro, ffmpeg-api.com, and Shotstack (in custom mode) sit in this group. The access isn't unlimited on FFmpeg Micro: raw options come from a documented allowlist covering codecs, CRF, bitrates and encoder presets, -vf and -af filters, -map, seeking and trimming, and frame and pixel-format options. The raw -filter_complex option is rejected, because multi-input filter graphs go in a separate filters array instead.

Preset-only APIs give you a menu of operations instead. Pick "720p" or "webm" and the service handles the rest, which is how Creatomate and Mux work. Faster to start with, but you'll hit walls when you need something the presets don't cover.

A third group isn't FFmpeg at all. AWS MediaConvert and Cloudflare Stream do video processing with proprietary transcoders, so if you need specific FFmpeg behavior (particular filters, codec options, format quirks), the output won't match what your local ffmpeg produces.

The six options worth considering

The table below compares how much FFmpeg each service exposes and how it charges.

AWS MediaConvert, Mux, and Cloudflare Stream are intentionally excluded. They're video infrastructure platforms, not FFmpeg APIs. If what you need is HLS packaging, DRM, or a video CMS, no FFmpeg API in that table will give you one.

What to actually evaluate

Four questions decide it: how much raw FFmpeg you get, how files arrive, how the meter runs, and whether it fits your tooling.

Can you pass custom FFmpeg options?

Custom FFmpeg options are the first thing to check in any of these services. If you need to set a specific CRF value, use a particular audio codec, or apply a filter graph, a preset-only API won't work no matter how good the docs are.

FFmpeg Micro takes raw options alongside or instead of presets:

{
  "inputs": [{ "url": "https://example.com/input.mp4" }],
  "outputFormat": "mp4",
  "options": [
    { "option": "-c:v", "argument": "libx265" },
    { "option": "-crf", "argument": "28" },
    { "option": "-preset", "argument": "slow" }
  ]
}

That's a POST /v1/transcodes call. It turned a 0.99 MB H.264 test clip into a 0.50 MB HEVC file. You get back a job ID, then poll GET /v1/transcodes/{id} until the status is completed, failed, or canceled. There are no completion webhooks: a webhookUrl in the request is ignored, so build your integration around polling from the start. The allowlist of accepted options is published in the FFmpeg Micro options reference, which is worth reading before you design around a flag that turns out to be rejected.

How does input work?

Input handling splits these services into two camps: URL-only, where you host the source file, and direct upload. FFmpeg Micro supports both. Pass a public URL in the inputs array, or use the three-step upload flow: get a presigned URL, PUT the file to cloud storage, confirm the upload.

For automation workflows in n8n or Make.com, URL-based input is simpler. You don't have to shuttle binary files through your automation platform.

What does it actually cost?

Duration-based pricing (FFmpeg Micro, ffmpeg-api.com) scales linearly with video length. A 1-minute video costs the same whether you're outputting 720p or 4K. FFmpeg Micro meters per second of input with no rounding up to the minute, so trimming a 30-second clip out of a one-hour recording bills 30 seconds, not the hour, and failed jobs are never billed. The plans are public on the pricing page: Free at $0, Starter at $19.99/month for 2,500 tokens, Pro at $49.99/month for 7,000. One token buys 10 seconds of input, which puts Starter at about 6.9 hours of video a month and Pro at about 19.4.

Per-file pricing (Rendi) charges per operation regardless of length. Cheap for long videos, expensive if you're processing thousands of short clips. Per-render pricing (Shotstack, Creatomate) depends on output complexity, so templates with multiple layers cost more.

For most developers processing user-uploaded content, duration-based pricing is the most predictable.

How does it fit your stack?

Stack fit decides the choice more often than features do. If you're building with n8n or Make.com, check for native integrations: FFmpeg Micro has an official Make.com app in the Make.com marketplace and an official n8n community node, @ffmpeg-micro/n8n-nodes-ffmpeg-micro, with more than 1,800 downloads. Rendi also has Make.com support, and Creatomate has the deepest Zapier integration. More than 300 builders have run FFmpeg Micro from Make or n8n.

From code, FFmpeg Micro has official SDKs for Python (pip install ffmpeg-micro, Python 3.8 or later) and PHP (composer require ffmpeg-micro/ffmpeg-micro-php, PHP 8.1 or later). From Node.js, Go, or anything else, you call the REST API directly. There's also an MCP server if the caller is Claude or another agent rather than your own code. Either way the differentiator stops being the HTTP client and becomes documentation quality and error handling: what the service tells you when an input is corrupt, an option is rejected, or a job fails halfway. If the job you need is a common one, like stamping a watermark, burning captions, or reframing to 9:16, the blueprints run it without writing the request at all.

Alexander Schmucker, Co-Founder of TipsyTech Games, describes the before-and-after in his own terms: three to four minutes of hand-editing per video became an automated pipeline.

Do you need multi-input composition?

Multi-input composition covers stitching clips together, overlaying audio on video, and building a slideshow from stills, and it's where preset-only APIs fail quietly. Sending several inputs with nothing but a preset does not concatenate them. Two 10-second inputs submitted that way came back as a single 10-second output, not 20 seconds. Concatenation needs a real filter graph:

{
  "inputs": [
    { "url": "https://example.com/clip1.mp4" },
    { "url": "https://example.com/clip2.mp4" }
  ],
  "outputFormat": "mp4",
  "filters": [
    { "filter": "[0:v][0:a][1:v][1:a]concat=n=2:v=1:a=1[v][a]" }
  ],
  "options": [
    { "option": "-map", "argument": "[v]" },
    { "option": "-map", "argument": "[a]" },
    { "option": "-c:v", "argument": "libx264" },
    { "option": "-c:a", "argument": "aac" }
  ]
}

One job takes up to 10 inputs, and any filter graph that combines them goes in the top-level filters array, which FFmpeg Micro runs as FFmpeg's filter_complex. The -map options then pick which of the graph's labeled outputs end up in the file. The request above turned two clips of 5.8 seconds each with audio into one 11.5-second H.264/AAC file. Simple cases skip the graph entirely: -map 0:v -map 1:a -c:v copy -c:a aac -shortest takes the video from the first input and the audio track from the second.

Pitfalls that surface after you've committed

Four assumptions cause most of the rework, and all four are cheap to test during an evaluation and expensive to discover in production.

Assuming a completion callback exists is the most common mistake. FFmpeg Micro has none, and a webhookUrl is ignored, so build the worker as a poll loop against GET /v1/transcodes/{id} from day one. Status checks are free.

Input size caps bite next. The maximum input file is 100 MB on Free, 1,024 MB on Starter, and 2,048 MB on Pro, so a 2 GB screen recording is a non-starter on the free tier until you trim or compress it first. Test with your largest real file, not a sample clip.

A request prototyped from a working local command can fail on a rejected flag like -filter_complex, so check the options reference before you build around one.

Last, pricing shape matters more than price. Thousands of 8-second UGC clips are punishing under per-file billing and cheap under per-second duration billing; one 90-minute webinar a week is the reverse. Count your real monthly minutes and your real clip count, then do the arithmetic for each model. Top-ups work on any plan including Free (500 tokens for $5, 1,200 for $10, 3,000 for $25), so a spiky month doesn't force a plan change.

Where an FFmpeg API is the wrong answer

An FFmpeg REST API is the wrong tool for three jobs. It won't do adaptive-bitrate streaming, DRM, or a video CMS; that's a managed streaming platform's job. It isn't an editing UI, so a drag-clips timeline is yours to build on top. And if your pipeline is one ffmpeg -i in.mp4 out.webm on a machine you already patch, an API just adds a network hop. The case starts when the queue, retries, scaling, and FFmpeg upgrades become your problem.

The decision framework

Pick based on your actual constraints, not feature lists. The question underneath all of these is how much FFmpeg you'll need six months from now, because that's the part you can't add later.

Most readers need real FFmpeg over REST, which leaves the three services that accept raw options or filter graphs, with the meter and integration breaking the tie.

Try FFmpeg Micro free

More than 700 developers and automation builders run video through FFmpeg Micro from their own code, from Make and n8n, and from AI agents. Grab an API key at ffmpeg-micro.com, send the transcode request above, and see your first output in under a minute: 200 tokens on sign-up, about 33 minutes of video, no credit card and no FFmpeg install.

FAQ

Is there a free FFmpeg API?

FFmpeg Micro offers a free tier with 200 tokens at sign-up, about 33 minutes of video, with API access, unlimited API keys, and no card required. The 100 MB input cap is the real constraint on that tier. Among the alternatives, template-based services typically offer a limited free render allowance, and at least one command-passthrough service requires payment up front.

Can I use FFmpeg in a serverless function?

You can run FFmpeg inside a serverless function, but the binary is 80 MB+ and cold starts get painful fast. An FFmpeg REST API avoids that: your AWS Lambda or Vercel function makes one HTTP call instead of spawning a local FFmpeg process.

What's the difference between an FFmpeg API and a video encoding service?

An FFmpeg API gives you direct access to FFmpeg's own options and filters over HTTP. A video encoding service like AWS MediaConvert uses a proprietary transcoder with a different feature set. If you need specific FFmpeg filters, codecs, or flags, you need an actual FFmpeg API.

How fast is cloud-based video processing?

Processing time depends on the input's length and the complexity of the operation, so H.265 at a slow preset takes considerably longer than a copy-codec trim of the same file. FFmpeg Micro reports progress by polling: call GET /v1/transcodes/{id} with the job ID until the status is completed, failed, or canceled. Billing follows the duration of the video, not how long the servers took.

Can I process videos in bulk through a REST API?

Bulk processing works by submitting every file as its own job and tracking each one by its job ID. FFmpeg Micro returns each result independently, so a 200-file batch is 200 submissions and 200 polls, and any job that fails costs nothing. For batch workflows, pair it with n8n or Make.com to process files from a folder, a form submission, or a scheduled run.

Last verified: October 2026. Every request in this post was run against the FFmpeg Micro production API (FFmpeg 7.0.2).