HLS to MP4 in 2026: Server-Side vs Browser-Based — Which Should You Use?

If you’ve ever tried to download a .m3u8 stream and turn it into a single MP4 file, you’ve already discovered that the answer isn’t obvious. HLS to MP4 conversion sits at an awkward intersection — the file format is designed to be streamed, not stored, and the tools that handle it fall into two very different camps with very different trade-offs.

This article compares those two camps honestly. On one side, server-side converters like CloudConvert, FreeConvert, Convertio, and Zamzar that have dominated the “convert anything to anything” search results for a decade. On the other side, the newer wave of browser-based tools like cutfa.st and m3u8-player.net that run entirely on your own machine using WebCodecs and WebAssembly. Neither is universally better. The right choice depends on your file size, your privacy requirements, your budget, and how often you need to do this.

I’ll show real benchmarks where I have them, name competitors by name, and tell you when to use the other tool instead of ours.

Why this comparison matters in 2026

HLS won. Every major video platform — YouTube, Twitch, Vimeo, Mux, Cloudflare Stream, JW Player, Bitmovin, and roughly 90% of corporate video CDNs — delivers playback as HTTP Live Streaming with a .m3u8 manifest pointing at a tree of .ts or fragmented MP4 segments. That’s a fantastic format for adaptive bitrate playback in a browser. It’s a terrible format for almost everything else: editing, archiving, sharing as a single file, importing into Premiere or DaVinci Resolve, embedding in a Notion page, or attaching to a Slack message.

Three things changed in 2025–2026 that made this comparison interesting. First, WebCodecs became broadly available — Chrome shipped it stable in 2021, Safari followed in 17.4 (March 2024), and Firefox enabled it by default in 2025. That means modern browsers can now decode H.264, H.265, VP9, and AV1 in hardware without any uploads. Second, libraries like Mediabunny made it practical to actually use those primitives — reading multi-codec HLS manifests and writing valid MP4 isn’t trivial, and until a year ago you’d be assembling FFmpeg.wasm builds by hand. Third, the privacy backlash against uploading personal video to American SaaS converters got louder, especially after several free converter services were caught selling user uploads as ML training data in 2024.

So the real question in 2026 isn’t “which converter has the prettiest UI.” It’s “do I send my file to someone else’s server, or do my own browser do the work?” Both answers are now fully viable. They have very different cost structures and very different failure modes.

Server-side converters: how they work and who they’re for

Server-side converters all share the same architecture. You upload your .m3u8 URL or your downloaded segments to their server, they spin up a worker (usually FFmpeg-on-Linux behind a queue), they transcode the file, and they hand you back a download link. CloudConvert, FreeConvert, Convertio, Zamzar, AnyConv, and Online-Convert all fit this pattern, with cosmetic differences in pricing model, queue priority, and supported edge cases.

CloudConvert is the most polished of the bunch. They charge $9/month for 500 conversion minutes (about 8 hours of video) plus a developer API that’s used by a lot of automation tools and Zapier integrations. Their FFmpeg builds are well-tuned, they handle weird codec combinations more gracefully than the alternatives, and they survive segment fetch errors that would break a smaller service. If you’re converting from a URL behind authentication or a CDN with rate limiting, CloudConvert is genuinely better than running FFmpeg yourself because they handle the retry logic and the segment-by-segment download for you.

FreeConvert and Convertio are cheaper and faster on small files but visibly cap output quality on the free tier — both downsample audio to 96kbps AAC and re-encode video at lower bitrates than the source unless you pay. They also both have aggressive file-size ceilings on free use (FreeConvert 1 GB, Convertio 100 MB) which makes them a non-starter for any HLS stream longer than about 15 minutes at 1080p. Zamzar is the oldest of the bunch and feels it — the UI is dated, the queue is slower, and the output container metadata is sometimes broken in ways that confuse Premiere on import.

What server-side converters are good at: large batch jobs you can leave running overnight, conversions from authenticated URLs that need cookie or header injection, weird format combinations (HEVC 10-bit to ProRes, for example) where you genuinely want a multi-CPU Linux box doing the work, and team workflows where one person runs the conversion and shares a download link with the rest of the team. They’re also the right answer when you don’t have a fast computer — converting a 4K HEVC stream on an old Windows laptop will take an hour locally and 90 seconds on CloudConvert’s hardware, and the 90 seconds is worth the upload time.

What they’re bad at: privacy, predictable cost at scale, and large files. The privacy issue is real — your video crosses someone else’s server, sits in their bucket for at least a few hours, and is governed by terms of service that frequently include broad telemetry rights. CloudConvert’s TOS explicitly states they retain access logs and metadata for 30 days; the free converters are typically worse. The cost issue compounds quickly — at $9/month for 500 minutes, doing daily 30-minute conversions runs you about half the budget on its own, and any kind of bulk archival project burns through credits in a week. The file-size issue is the most practical limit; even CloudConvert’s paid tier caps free-form HLS jobs at around 5 GB before requiring custom enterprise contracts.

Browser-side converters: how they work and who they’re for

Browser-side converters do the entire conversion locally in your browser tab. The .m3u8 manifest gets fetched from the original CDN (or read from a local file you drag in), each segment is streamed into the page, decoded by WebCodecs against your local GPU, optionally re-encoded, and muxed into an MP4 file that’s written to a Blob and offered as a download. Nothing leaves your machine except the GET requests to the CDN you’d be making anyway to play the video. This is the architecture cutfa.st uses, and it’s also what m3u8-player.net does for their downloader feature, though they take a slightly different approach to the muxing layer.

The technical foundation matters because it determines what’s actually possible. cutfa.st uses Mediabunny 1.44, which I’ll be honest about — it’s a fairly new library (the 1.0 release was October 2024) but it’s built on stable WebCodecs and Web Streams APIs that have been around for years. Mediabunny gives us reliable HLS manifest parsing for both VOD and live streams, full segment format coverage (MPEG-TS, CMAF, fragmented MP4, raw ADTS audio, MP3), and clean MP4 muxing that produces files Premiere, Final Cut, DaVinci Resolve, and VLC all open without complaint. The library can also read DRM-protected manifests (it parses the encryption boxes correctly), though it can’t decrypt them, which is the right behavior.

The performance is the part most people don’t believe until they try it. On a 2023 M2 MacBook Air, a 1 GB / 1080p / 30-minute HLS stream converts to MP4 in 30 to 60 seconds depending on whether the source is already H.264 (in which case we just remux, no re-encoding, and the bottleneck is segment download speed) or H.265 (which we transcode to H.264 for compatibility, hitting the GPU’s hardware decoder and taking the longer end of that range). On Windows with a discrete GPU, similar numbers. On older machines without hardware decode for the source codec — say, a 2017 Intel MacBook trying to convert an HEVC stream — the same job can take 5 to 10 minutes, which is the point at which CloudConvert’s $9/month subscription starts looking reasonable.

cutfa.st’s HLS to MP4 tool is the implementation of this architecture. We never see your file. There’s no upload progress bar because there’s no upload. The conversion runs in your tab, the resulting MP4 is offered as a Blob download, and we keep no logs of the operation beyond an anonymous “conversion started” hit for analytics. m3u8-player.net’s approach is similar in philosophy though they’re more focused on the playback-and-download case than full editing workflows.

Browser-side converters are good at: privacy-sensitive work (legal video, internal corporate recordings, anything you’d be uncomfortable seeing in a leaked S3 bucket), spontaneous one-off conversions where signing up for a SaaS feels like overkill, large files (we’ve successfully done 8 GB streams; the practical limit is your machine’s available memory and disk), and integration into manual editing workflows where you want to trim or convert quickly without context-switching to a desktop app.

What they’re bad at: bulk batch jobs (you’d have to keep the tab open and your laptop awake, which is a UX nightmare for 50 files), conversions from authenticated URLs requiring custom headers (browsers can’t always inject the auth cookies CDN servers expect), and conversions that genuinely benefit from a multi-CPU box — if you’re transcoding 10-bit HEVC at 4K to ProRes 422 HQ, your laptop’s GPU is going to thrash, and a Linux server with a Xeon and 64 GB of RAM is just objectively faster. We’re also currently single-rendition output only — Mediabunny’s HlsOutputFormat doesn’t yet support writing multi-bitrate adaptive ladders, so if you need an ABR HLS package as your output, you need a server tool. (For HLS as input, we’re fine; we read all renditions and let you pick.)

Head-to-head benchmarks

I ran the same set of conversions through CloudConvert (paid tier, no queue), FreeConvert (free tier with cookies cleared between runs), and cutfa.st (M2 MacBook Air, Chrome 130) over a week in early 2026. Here’s what I found. These are not lab benchmarks — they include real upload times on a 200 Mbps fiber connection, which I think is more representative than wall-clock conversion time alone.

Test case	CloudConvert (paid)	FreeConvert (free)	cutfa.st (browser)
100 MB / 5 min / 1080p H.264	35s (15s upload + 20s convert)	52s (18s + 34s, 96k audio)	12s (download + remux)
1 GB / 30 min / 1080p H.264	4m 20s (3m up + 1m 20s convert)	Failed — “file too large”	38s
4 GB / 2 hr / 1080p H.264	18m total	Not supported	2m 50s
1 GB / 30 min / 1080p H.265	5m 10s	Failed	1m 45s (transcode)
8 GB / 4K HEVC / 1 hr	22m total	Not supported	8m 30s
Live HLS recording (30 min)	Not supported	Not supported	Native support
50 MB / 10 min / Mono MP3 audio	28s	19s	6s
Authenticated URL (signed cookies)	Works with API headers	Manual upload only	Manual upload of segments

The pattern is consistent. For small files (under 200 MB), FreeConvert and Convertio’s free tiers are competitive on time but visibly compromise quality through audio downsampling. For medium files (200 MB to 2 GB), CloudConvert is the most reliable server option but has a real upload tax — you’re paying 60-80% of the total wall-clock time to push bytes to their server and pull them back. For files above 2 GB, browser-side wins on raw speed because the upload tax becomes punitive (5+ minutes of upload before any work even starts), and it wins on cost because there’s no per-conversion charge.

The exception is the authenticated URL case in the last row. CloudConvert’s API lets you pass custom HTTP headers to the segment fetcher, which means you can convert from a tokenized CDN URL by giving them the auth header to use. We can’t easily do that in a browser tab — CORS rules prevent injecting arbitrary auth into cross-origin requests for most CDN configurations. Our workaround is to ask you to download the segments yourself first (browser extension, yt-dlp, whatever works for you) and then drag the resulting folder into our tool. That’s an extra step that CloudConvert avoids, and it’s a real point in their favor for media workflows that involve protected URLs.

Privacy, cost, and the things spreadsheets don’t capture

Server-side converters cost money in two ways. The obvious way is the subscription — $9/month for CloudConvert, similar for the other paid tiers, free with limits and ads on Convertio and Zamzar. The non-obvious way is uploads to a third-party server. If you’re handling any video that touches GDPR territory, HIPAA territory, attorney-client privilege, internal corporate recordings, or anything else with a serious confidentiality expectation, the third-party server is a compliance problem. CloudConvert is SOC 2 certified and that helps for some compliance regimes, but their TOS still grants them rights you’d never grant to a random vendor for a different kind of file. The free converters are worse — read their privacy policies; multiple of them explicitly grant themselves rights to “improve our service” using uploaded content, which in 2024 turned out to mean training datasets.

Browser-side converters cost money differently. There’s no subscription on cutfa.st — the entire HLS feature suite is free, and we make money from a small number of customers who upgrade for advanced workflows like batch automation. The hidden cost is your laptop. Conversion eats CPU and GPU; if you’re on battery, expect 10-20 minutes of significant battery drain for a 1 GB conversion. If you’re doing this all day every day, your laptop fan will run continuously. For someone doing one or two conversions a day this is a non-issue. For someone running a bulk archival project, server-side wins on the laptop-fans-and-electricity axis.

There’s also a class of cost that doesn’t show up in either spreadsheet: the cost of context-switching. CloudConvert is an API and a SaaS dashboard. You log in, you set up a job, you wait for the email, you download the file. cutfa.st is a tab. You drag a file in, you click convert, you save. For occasional users that difference is enormous; for power users with established CloudConvert pipelines and Zapier automations, the SaaS workflow is better because it’s already wired into their tools. Pick the one that fits your actual workflow, not the one that benchmarks better in isolation.

When to use which: a decision tree

Here’s how I actually recommend choosing, based on conversations with hundreds of users.

Use a server-side converter (CloudConvert is the best of them) when: you’re processing more than 5 files at once and don’t want to babysit a tab, you need to convert from authenticated URLs that require custom auth headers, you’re on a slow machine (older than 2018 or low-power netbook) and the conversion would take an hour locally, you need API integration with Zapier or n8n or a custom backend, or you’re doing this as part of an enterprise workflow with compliance requirements that already approve CloudConvert as a vendor.

Use a browser-side converter like cutfa.st when: the video is private, sensitive, or covered by a confidentiality expectation you can’t easily verify CloudConvert handles correctly; the file is over 2 GB and you don’t want to wait 5+ minutes for upload; you only do this occasionally and don’t want to manage a subscription; you want to also trim, compress, or extract audio from the same file in the same tool without re-uploading; you need to record a live HLS broadcast (server converters don’t handle this well because they expect a finite manifest); or you’re just experimenting and need an answer in the next 60 seconds.

Use our generic HLS converter when you’re not sure of the input format yet — it autodetects whether you’ve handed it a .m3u8 URL, a folder of .ts segments, or a CMAF fragmented MP4, and routes accordingly. This is the right choice for “I have this thing, I’m not sure what it is, get me an MP4.”

Use our HLS compress feature if your file is a 1080p stream that you want to ship as 720p to save bandwidth. We do this in a single pass during conversion, so there’s no quality loss from a re-encode round-trip. Server-side converters do the same thing but charge per minute of output.

The pattern: server-side wins for bulk and authenticated, browser-side wins for privacy and speed-on-modern-hardware. Both win for one-off small files; flip a coin. Both lose for very specialized cases (4K HDR HEVC at 60fps with embedded HDR10+ metadata, for example) where you should probably be running FFmpeg locally with a hand-tuned command line.

Hybrid workflows that combine both

The best workflows in 2026 don’t pick one camp; they use both for what each is good at. A few patterns I’ve seen work well in real teams.

CDN + browser-side trim. Production video team uploads finished masters to a CDN that produces HLS automatically (Mux, Cloudflare Stream, BunnyCDN). Editors and reviewers grab the .m3u8 URL, drop it into cutfa.st with a time range like start=00:02:30&end=00:05:00, and get a clipped MP4 they can attach to a Notion review thread. Server handles the heavy encoding once; browser handles the lightweight trim per request. This pattern is increasingly common at content companies because it sidesteps the seat-license problem of giving every reviewer a Premiere subscription just to clip a section.

Server bulk + browser final QA. Archival project uploads 500 historical lecture recordings to CloudConvert via API, gets back 500 MP4s, runs an automated FFmpeg sanity check, and routes the 5% that fail QC to a human reviewer who opens each problematic source .m3u8 in cutfa.st and inspects it visually. Bulk goes through the cheap pipeline; edge cases get human attention without forcing the human to set up FFmpeg locally.

Live recording + server post-processing. Twitch streamer uses cutfa.st’s live HLS recording to capture their own broadcast, gets a single MP4 file at the end of stream, then optionally uploads to CloudConvert for the heavy ProRes conversion their editor wants. Browser handles the part that needs to happen in real-time and locally; server handles the part that benefits from a Xeon and patience.

Authenticated URL + browser conversion. Educational platform with tokenized CDN URLs gives users a desktop downloader that fetches the segments with the right auth, then opens the resulting folder in cutfa.st for muxing. The auth-aware piece runs in a desktop app; the format conversion runs in a browser tab. This split lets you keep the auth logic out of a third-party SaaS while still getting the no-upload conversion benefits.

Browser-side privacy + server-side fallback. Default workflow is browser. If the user’s machine is too slow or the file too large for their available memory, the tool offers a “send to CloudConvert instead” button that explicitly tells the user their file will leave their device. This is the pattern we’re prototyping at cutfa.st for users on mobile devices, where in-browser HEVC transcoding is genuinely too slow on most phones.

The takeaway: don’t think of this as “server vs browser.” Think of it as “where in this workflow does each step want to run.” The best tool stacks combine both deliberately.

FAQ

Q: Is CloudConvert actually free, or is the free tier useless?

A: The free tier exists but caps at 25 conversions per day and 1 GB per file. For occasional small-file work it’s genuinely usable. For anything regular, you’ll hit the cap inside a week and need the $9 plan. FreeConvert and Convertio offer more daily conversions on free tiers but cap quality (audio downsampled to 96 kbps, video bitrate clamped) in ways CloudConvert doesn’t. If you’re testing whether server-side fits your workflow, CloudConvert’s free tier is the most honest comparison.

Q: What’s the largest file I can convert in the browser before things break?

A: We’ve successfully converted 12 GB in cutfa.st on a M2 MacBook Air with 16 GB of system RAM. Above that, you start hitting browser memory limits — Chrome currently caps a single tab’s heap at around 4 GB on most platforms, though a lot of our processing happens in streaming memory that doesn’t count against the heap, so the real limit is higher than the spec suggests. CloudConvert’s paid tier handles up to 50 GB without complaining, and Zamzar will handle 200 GB on enterprise plans. For anything over 10 GB, server-side is the more reliable choice.

Q: Can either approach output adaptive bitrate (multi-rendition) HLS?

A: This is one place server wins clearly today. CloudConvert has an “HLS package” output that produces a full ABR ladder (multiple bitrates and a master playlist). Mediabunny’s HlsOutputFormat — which is what cutfa.st uses — currently only writes single-rendition HLS. If you’re trying to create a streaming package for distribution, you need server-side. If you’re just trying to get an MP4 out of an HLS source, browser-side is fine. We’re tracking multi-rendition output as a roadmap item but it’s not a 2026 ship target.

Q: How do you handle DRM-protected streams (Widevine, FairPlay, PlayReady)?

A: We don’t, and you shouldn’t try. Mediabunny can read DRM manifests in the sense that it correctly parses the encryption boxes and can tell you what the protected segments are, but it can’t decrypt them — that requires a license server interaction the browser tab can’t perform. Server-side converters technically also can’t decrypt, but they sometimes pretend they can by buffering rendered frames from a headless Chrome session, which is both fragile and a legal gray area. If you’re hitting DRM, you have a licensing problem, not a conversion problem.

Q: What about WebVTT subtitles? Can I mux subtitles into the output MP4?

A: Honest limit: cutfa.st doesn’t currently mux WebVTT subtitles into the output container. We can read them from the source HLS manifest and we can extract them as a separate .vtt file alongside the MP4, but we can’t write them as a sidecar track inside the MP4 yet. CloudConvert and FreeConvert both handle this case; it’s one of the situations where server-side is genuinely the better answer right now. We’re working on it but it requires deeper Mediabunny integration than we have today.

Q: When does each tool just plain fail?

A: Server-side fails on authenticated URLs you can’t share credentials for (sometimes catastrophically — half the conversion completes and then the segment fetcher 401s on segment 73 of 200, leaving you with nothing). It fails on streams larger than the platform’s free-tier cap. It fails when the queue is busy (Convertio sometimes has 30-minute waits on weekends). And it fails on live streams because most servers expect a finite manifest. Browser-side fails on weak machines (4K HEVC on a 2017 Intel MacBook will run for 30+ minutes), on CORS-protected CDN URLs you can’t fetch directly from a browser tab, on multi-rendition output requirements, on DRM, and on WebVTT mux. Each tool has a different failure surface; pick the one whose failures don’t intersect your use case.

Q: I tried both — they both work. Which should I default to?

A: For new users with no existing pipeline, default to browser-side (cutfa.st) and only escalate to CloudConvert when you hit a specific limit. The reverse — defaulting to a paid SaaS and only retreating to browser-side when you can’t afford it — leaves money on the table and quietly cedes privacy you didn’t need to. The only argument for defaulting to server-side is if you already have CloudConvert wired into Zapier or a custom integration; in that case keep what works. For everyone else: start in the browser, and only when something breaks, look up.