FFmpeg API pricing compared

I build one of the services on this list. That is a reason to read the numbers rather than the adjectives, so this post is mostly numbers, and two competitors come out ahead of us on the workload we measured. All competitor figures were read off their own live pricing pages on 2026-08-20.

Short version#

Six services, five different billing units, and the unit matters more than the price.

Entry prices span $7 to $25. The quotas behind them differ by more than 100x once you convert them into the same work, so the headline price tells you close to nothing on its own.

The workload we priced against#

Rather than invent a hypothetical, we used our own job history. Rendobar’s account has run 1,978 jobs between 2026-03-17 and 2026-08-20. Of those, 1,770 were billed and the total was $14.16.

The distribution:

85.1% of every job ever run on this account cost under a cent. 73.4% cost under half a cent.

Narrowing to FFmpeg jobs specifically, the last 425 runs since 2026-08-01 had a median of $0.0025, a 90th percentile of $0.0042, a minimum of $0.0008 and a maximum of $0.0073. Every single one was under a cent.

This is a specific shape of workload and its shape is the point: many short jobs on small files, averaging about 386 jobs a month. Hold that in mind, because it is exactly the shape that per-GB pricing does not notice and per-command pricing punishes.

What that workload costs everywhere else#

At roughly 386 jobs a month on files around 350 KB:

Two of those rows are measured and two are estimated, so read them differently. The Rendi row is solid: the 1,192 output files this account produced total 1.98 GB across all five months, which is under 4% of one month of its free allowance, and adding the inputs cannot move it near 50 GB. The FFmpeg Micro row is an estimate, because the archive does not record total input duration. It comes from 386 jobs a month against a median source of 5.013 seconds, which is roughly 32 minutes.

Two competitors would have run this workload for nothing. That is a real result and it is worth saying plainly: if your files are small and your volume is moderate, a per-GB or per-minute free tier is very hard to beat. Rendi asks for a card and a $5 refundable hold to get there, and FFmpeg Micro caps input files at 100 MB on free, but neither of those is a price.

Where we would point out a difference rather than a price: on Rendi’s free tier a single command is capped at 1 minute of runtime and 4 vCPUs, and on FFmpeg Micro free the input file cap is 100 MB. Those ceilings are what the free tier costs you.

Why the ranking inverts on big files#

Take the opposite workload. A hundred jobs a month, each a 1 GB source that takes ten minutes to process.

Per-GB pricing now dominates the bill. 100 GB a month blows straight through Rendi’s 50 GB free tier and into the $25/mo Pro plan, whose base allowance is 100 GB.

Per-command pricing now looks cheap on quota and expensive on limits. RenderIO’s Starter plan is $12 for 500 commands, and 100 commands fits easily, but Starter caps a command at 1 minute. Ten minutes of processing needs the Business plan at $99/mo, where the cap is 20 minutes. The quota was never the constraint. The runtime ceiling was.

FFmpeg Micro’s tokens are metered on input duration at 3 per 10 seconds, so long sources consume tokens linearly and 100 long files exceeds the 7,000-token Pro tier.

We are not going to give you a Rendobar number for that workload, because we have not measured it. Our archive is short clips. Compute cost does not extrapolate cleanly from a 5 second clip to a 10 minute one, and publishing a number we derived by multiplication would be the same guesswork we are criticising. If large files are your workload, measure your own on a free tier before believing anyone’s table, including this one.

Reading the five billing units#

Per GB processed (Rendi) meters bytes in. It is indifferent to how hard the work is, so a cheap remux of a large file and an expensive AV1 encode of the same file cost the same. Good for small files and for CPU-heavy work on modest inputs. Bad for archives of large sources you touch lightly.

Per GB-second (ffmpeg-api.com) meters memory multiplied by time, the Lambda model. It tracks real resource use closely, and it is the hardest to predict in advance because you rarely know your memory footprint before you run.

Per command (RenderIO, and per call at ffmpegapi.net) is the easiest to forecast and the least connected to cost. One command is one command whether it trims a 2 second clip or transcodes an hour. That predictability is genuinely valuable in a budget. It also means the plan’s runtime ceiling rather than its quota is usually what forces an upgrade, which is the trap in the section above.

Per token on input duration (FFmpeg Micro) meters source length. Predictable if you know your inputs, and indifferent to what you do with them, so a heavy multi-pass encode and a fast copy cost the same.

Per second of compute (Rendobar) meters the work itself. It is the closest thing to cost-plus and it is the least round number. You can see the whole distribution above, which is the tradeoff: no clean monthly figure, but no surprise upgrade either.

The subscription question#

Five of the six services here require a monthly subscription to do anything beyond a free tier. The quota resets, unused quota disappears, and a month where you process nothing still costs the full amount.

Rendobar sells credits instead. The $5 signup grant needs no card, credits do not expire monthly, and the $9/mo Pro plan buys operational limits (20 concurrent jobs against 1, a 9 hour job timeout against 1 hour, 10 GB input files against 500 MB) rather than a processing quota. Pro includes $5/mo of credits and a 20% bonus on purchased credits.

Whether that is better depends on how steady your volume is. A predictable pipeline running the same load every month gets a clean number out of a subscription. Bursty or seasonal work pays for months it did not use.

Where this stops#

Every competitor figure here came off a live pricing page on 2026-08-20 and pricing pages change. Verify before you commit to anything.

We could not read Very Good FFmpeg’s pricing from its served HTML, so it is not in the table rather than being priced at a guess. ffmpeg-api.com’s free-plan quota is not stated on their pricing page and their GB-second model cannot be converted without a memory figure they do not publish.

The workload we normalised against is ours: 1,770 billed jobs, mostly short clips, mostly small files, run by a team building and testing a media API. It is a real workload and it is not your workload. The one number here that transfers is the shape of the argument, which is that you should convert every plan into your own unit before comparing any of them.

Nothing here measures reliability, speed, support, or whether the service will exist next year. Those are not pricing questions and this is a pricing post.

For the wider comparison including what each service actually lets you run, see the best FFmpeg API in 2026. For what a single job costs and why, see FFmpeg encoding settings measured.