Video Download Error: Unsupported Format or Source? What It Means

An unsupported format or unsupported source message can be confusing because the video may look completely normal when you open it in your browser.

The page loads. The video plays. Your phone can watch it. Yet when you paste the same link into a downloader, the result may be something like an unsupported-source, unsupported-format, extraction, or processing error.

The important thing is that these messages do not all mean the same thing.

Sometimes the website itself is not supported. Sometimes the website is supported but that particular video cannot currently be extracted. Sometimes the requested quality is not available. In other cases, the media exists but its streams or codec/container combination cannot be used with the requested output.

And sometimes the problem has nothing to do with the video format at all.

This guide explains how to tell those situations apart and what you can safely try.

What Does "Unsupported Source" Actually Mean?

A source is the website, URL, or media service where the video is hosted.

An unsupported-source problem generally means the downloader cannot currently identify or extract usable media from that source URL.

That can happen because:

the website does not have a compatible extractor the URL pattern is not recognized the website changed its internal structure the page does not actually contain an extractable video the URL points to an unusual page rather than the media page the source requires an access method the downloader does not support the extractor is temporarily broken or outdated

yt-dlp maintains a large collection of site-specific extractors, but its own documentation makes an important point: a site appearing in the supported-sites list does not guarantee that every URL from that site will work. Websites change, and a previously working URL pattern can become unsupported.

A supported platform is not a guarantee for every video

Imagine that a platform generally works with a downloader.

That does not mean:

every video on that platform will always be extractable.

A particular video may be:

private unavailable region-restricted members-only protected delivered through a different media system missing usable formats affected by a recent platform change

So there is an important difference between:

"This platform is generally supported."

and:

"This exact URL and media item can currently be extracted."

That distinction is one of the most useful things to understand when troubleshooting.

What Does "Unsupported Format" Mean?

A media format describes how the audio and video are packaged and encoded.

This is where two terms cause a lot of confusion:

Container ≠ codec

A container is the file structure that holds media streams and related information.

A codec is the technology used to encode and decode the actual audio or video data.

For example, these are different combinations:

MP4 container + H.264 video MP4 container + HEVC/H.265 video WebM container + VP9 video WebM container + AV1 video

An MP4 extension alone does not tell you everything about the video inside it. MDN's current media documentation specifically notes that a video/mp4 type does not by itself identify the codec used inside the file.

Why MP4 does not always mean the same thing

Consider two files:

video-a.mp4

and

video-b.mp4

Both have an .mp4 extension.

But one could contain H.264 video while another could contain HEVC or another supported MP4-compatible codec.

The container is the same category, but the encoded streams can differ.

That is why simply saying "MP4 is supported" does not prove that every possible MP4 stream can be processed or played in every environment.

The same principle applies to WebM.

WebM is a container format designed for web media and is commonly associated with VP8, VP9, AV1, Vorbis, and Opus.

Why Codec and Container Compatibility Matters

A downloader has to do more than recognize a filename extension.

It may need to:

identify the available media streams determine their codecs select compatible video and audio streams place those streams into an appropriate output container use a media-processing tool when streams need to be merged or converted

FFmpeg describes this distinction through its demuxing and muxing architecture: demuxers read multimedia streams from containers, while muxers write streams into output containers.

This is also why renaming a file does not solve a codec problem.

Changing:

video.webm

to:

video.mp4

only changes the filename.

It does not change the encoded video or rebuild the container.

A genuine conversion or compatible remuxing operation has to process the media structure itself.

FFmpeg's documentation explains that stream copying can change the container without decoding and re-encoding, but that only works when the streams are compatible with the target container.

Why Audio and Video Can Be Separate

Modern video services do not always provide one file containing everything.

A source may expose:

a video-only stream an audio-only stream a combined video-and-audio stream several video qualities several audio qualities

yt-dlp supports selecting separate video and audio streams and merging them with FFmpeg when appropriate.

For example, a source might provide:

Video

1080p VP9

Audio

Opus

The downloader can potentially retrieve both streams and combine them.

But if the source does not expose a usable audio track, or if the selected streams cannot be combined into the intended output, the download pipeline may fail even though the video itself exists.

The same problem can happen in reverse: a source may expose audio but not provide a usable video stream for the requested quality.

Why a Video Can Play in Your Browser but Fail in MediaFetches

This is one of the most common points of confusion.

You might think:

"If Chrome or my phone can play it, why can't MediaFetches download it?"

Because playback and extraction are different operations.

A browser may receive media through a platform's normal playback system, handle JavaScript-driven requests, assemble media dynamically, use browser-specific codecs, maintain session state, or receive information through APIs that a downloader does not use.

A downloader has to discover and retrieve the underlying media streams through its extraction pipeline.

So:

Browser playback working ≠ downloader extraction guaranteed

Even yt-dlp's documentation warns that support is ultimately something that must be tested for the specific URL because supported websites can change their behavior.

A URL opening successfully in a browser also does not prove that the URL points directly to a downloadable media resource.

It may instead point to:

a webpage an embedded player a login page a dynamically generated player a page that requires JavaScript a protected media service

Six Different Problems That Can Look Like "Unsupported Format"

Not every unsupported-style error belongs to the same category.

1. The source is unsupported

The downloader does not have a working extraction path for that website or URL structure.

In this situation, changing from 1080p to 720p may not help because the downloader cannot reach the usable media layer in the first place.

1. The platform is supported but this individual item cannot be extracted

A platform may generally work while a particular video does not.

For example, one URL might expose ordinary video formats while another:

is private is restricted has unusual delivery has been removed has changed its media structure requires access that the downloader does not have

This is why "supported platform" should never be interpreted as "every URL on this platform is guaranteed to work."

1. The requested quality is unavailable

Sometimes the source works perfectly, but the particular quality you want is not actually exposed for that video.

MediaFetches examines the formats reported by the source and builds quality choices from the available video heights.

Its standard quality ladder includes:

144p 240p 360p 480p 720p 1080p 1440p 2160p

Higher-than-1080p options are only advertised when the source actually reports those heights.

That means a source does not get magically upgraded to 4K just because MediaFetches supports a 4K quality category.

The source determines what is available.

1. The media cannot be used with the requested output

A source can provide valid media while the selected streams still present a container or processing compatibility problem.

This is where FFmpeg becomes important.

MediaFetches uses FFmpeg as part of its media-processing pipeline. For video, the managed downloader targets an MP4 output and can merge separate video and audio streams.

The project uses stream-copy processing rather than re-encoding for the normal video MP4 path. That means it is not simply taking every possible codec and converting it into a completely different video codec.

FFmpeg itself notes that stream copying does not decode or encode the media and can fail when the target container cannot accept the source streams.

1. The extractor is temporarily behind the source

This is a different problem again.

Video platforms change their internal APIs, page structures, player systems, and delivery mechanisms.

An extractor that worked yesterday can therefore stop extracting a particular source today.

yt-dlp's own supported-sites documentation explicitly warns that websites are constantly changing and that this can break extractor support.

MediaFetches includes an automatic yt-dlp update-and-retry mechanism for extraction failures.

That mechanism is throttled rather than running an update for every failure. The project limits this best-effort update attempt to at most once per hour.

So an extraction failure can sometimes be temporary and extractor-related rather than a permanent limitation of the source.

1. The content is restricted or protected

Private, members-only, login-required, region-restricted, or DRM-protected content should not automatically be treated as a codec problem.

For example:

Private video

This is an access problem.

Members-only content

This is an access restriction.

DRM-protected media

This is a content-protection/access-control mechanism.

Trying to solve these situations by repeatedly changing quality or renaming extensions misses the actual problem.

MediaFetches specifically normalizes several such extraction conditions into separate user-facing messages rather than treating them all as ordinary format failures.

Do not attempt to bypass those restrictions.

How MediaFetches Handles Formats

Understanding the actual MediaFetches pipeline makes the error much easier to diagnose.

Source extraction

When you paste a URL, MediaFetches first validates that it is a public HTTP or HTTPS URL.

It also rejects private/internal addresses before passing the URL to the downloader engine.

The source is then passed to yt-dlp for metadata and format extraction.

The project does not maintain a separate hardcoded list that guarantees that every configured platform will work.

The current public configuration contains enabled entries for:

YouTube TikTok Instagram Facebook Reddit Vimeo Dailymotion VK Threads Pinterest

Those entries control the site's platform configuration and presentation. Actual media extraction still depends on what the installed/updatable yt-dlp extractor can currently process.

That distinction matters.

Available quality detection

MediaFetches does not assume that every source has every resolution.

It reads the formats returned by yt-dlp and checks which video heights are actually available.

If a source has 1080p but no 1440p, the 1440p option is not treated as genuinely available.

If a source reports a video but does not provide a usable resolution value, the project can expose a Best available option instead of inventing a resolution.

This is a better model than assuming that every source offers the same list of qualities.

Video and audio selection

MediaFetches does not give users a low-level codec or stream-selection panel.

Instead, it builds format selectors internally.

For a progressive source where video and audio are already together, it can select an appropriate combined format.

For sources where video and audio are separate, the project can use a video selector together with bestaudio and then merge them.

This follows the same general model supported by yt-dlp: separate video and audio formats can be selected and merged with FFmpeg.

MP4 output and FFmpeg

For managed video downloads, MediaFetches targets:

MP4

and uses FFmpeg for the merge/post-processing stage.

The project's normal video post-processing uses:

-c copy

That means the normal path is not a video re-encoding/compression tool.

It is primarily preserving the selected media streams while placing them into the intended output structure.

This is another reason why "unsupported format" does not automatically mean "MediaFetches can just convert it."

A conversion that changes the actual video codec would require a different processing operation.

An important MP4 edge case

There is an additional detail in the current project implementation.

MediaFetches prefers an MP4 result, but its managed download code does not blindly assume that every successful merge will produce .mp4.

If the selected codecs cannot be placed into an MP4 container, the underlying process may produce another container such as MKV. The project checks what was actually produced rather than falsely claiming that no file exists.

So the practical rule is:

MP4 is the intended video output, but the underlying media compatibility can affect the final container in edge cases.

The user does not get a manual container selector for choosing MP4, WebM, MKV, or another container.

MP3 audio extraction

For audio downloads, MediaFetches selects the best available audio source and uses FFmpeg to produce:

MP3

The project does not expose a manual audio-codec selector.

It also does not provide a user-facing control for choosing individual audio streams.

What MediaFetches does not let you manually control

The current project does not provide user controls for:

choosing a specific video codec choosing a specific audio codec choosing a container manually selecting an individual stream ID manually writing a yt-dlp format expression repairing a broken media container converting any arbitrary media format into any arbitrary format forcing unsupported sources to work

The normal interface is much simpler:

Paste URL → inspect available media → choose available quality/type → download

That is intentional.

How to Troubleshoot an Unsupported Format or Source Error

Use this order rather than randomly changing settings.

Step 1: Read the exact error

Do not immediately assume that the word "format" means codec incompatibility.

MediaFetches currently normalizes several yt-dlp extraction failures.

For example, when yt-dlp reports conditions such as an unsupported URL, no video formats, inability to extract, or no media found, MediaFetches can show:

"We couldn't read this link. It may not be a supported site, or the page may not contain a video."

Other extraction failures may instead produce:

"We couldn't process this link. Please check the URL and try again."

The current project does not have a dedicated user-facing error for every possible technical format/codec condition.

That means you should not interpret the exact phrase "unsupported format" as proof that the container or codec is definitely the cause.

Step 2: Check the URL

Make sure you copied the actual public video/page URL.

MediaFetches requires a valid public HTTP or HTTPS link.

It rejects URLs containing credentials and blocks private/internal destinations.

A malformed URL can therefore fail before the media extractor even gets a chance to examine the video.

Step 3: Check whether the source is public

Ask:

Can you open the video normally? Is it public? Has it been removed? Does it require membership? Does it require login? Is it region restricted?

If the answer involves access restrictions, changing from 1080p to 720p is usually not the right diagnosis.

Step 4: Determine whether the platform is generally supported

The current MediaFetches configuration lists several enabled platforms, but platform configuration should not be confused with guaranteed extraction support.

The real test is whether yt-dlp can successfully extract the specific URL.

This is consistent with yt-dlp's own documentation: even a listed site may currently be broken, and the only reliable test is trying the URL.

Step 5: Check the available qualities

If the URL is successfully read, look at the quality options MediaFetches provides.

If 1080p is unavailable but 720p is available, the source simply may not expose 1080p for that item.

This is not necessarily an error.

Try an actually available quality.

Do not assume that the highest quality category should exist for every video.

Step 6: Try a different available quality

Changing quality can help when the problem is tied to a particular representation.

For example:

2160p fails 1080p works

That suggests the problem may be associated with the higher-quality media representation rather than the entire source.

But if:

2160p fails 1080p fails 720p fails the source cannot even be analyzed

then repeatedly lowering quality is unlikely to solve an unsupported-source problem.

Step 7: Check whether audio and video are available

A modern source may expose separate streams.

For example:

video exists audio exists but the requested combination cannot currently be assembled

Or the source may expose video but no usable audio for a particular representation.

This is one reason a video can appear perfectly normal during browser playback while a downloader struggles to construct a standalone output file.

Step 8: Test whether the problem is source-specific

Try a different public, authorized video from the same source.

If another video works, the problem may be specific to the original media item.

If many unrelated videos from the same platform fail, an extractor or platform-change issue becomes more plausible.

If many different platforms fail, the problem may be broader than one particular source.

This simple comparison is often more useful than changing several settings at once.

Step 9: Consider an extractor update

yt-dlp is updated frequently because source platforms change their delivery systems.

MediaFetches includes an automatic best-effort yt-dlp update and retry after extraction failure, with a one-hour cooldown between automatic update attempts.

That means a temporary extractor problem can sometimes recover without any action from the user.

It does not mean every unsupported source will become supported after an update.

An update can fix an extractor bug, but it cannot magically create an extractor for a source that the software does not support.

Step 10: Try another supported source when appropriate

If the original source genuinely cannot be processed, a different public source may work.

For example, if the same authorized video is available from another supported location, that can help determine whether the problem is tied to the original source.

Do not use this as a method for bypassing access restrictions.

Step 11: Recognize when the source is genuinely unsupported

Sometimes there is no setting you can change.

If the extractor cannot recognize the URL or cannot obtain usable media streams, changing the filename, quality, or device will not create the missing extraction capability.

This is a capability limitation, not necessarily a user mistake.

Step 12: Recognize when no user-side setting can solve it

There are cases where the correct answer is simply:

There is currently no supported way to process this source through MediaFetches.

That can happen because:

the platform is unsupported the extractor is currently broken the individual media item is inaccessible no suitable streams are exposed the output requirements cannot be satisfied the content is access-controlled the content is DRM-protected

Knowing when to stop is part of good troubleshooting.

Real-World Examples "The webpage opens in my browser, but MediaFetches says it cannot read it."

This does not automatically indicate a MediaFetches bug.

A browser may execute JavaScript, maintain site state, negotiate playback requests, and use a platform's own player.

MediaFetches needs yt-dlp to identify the actual media source and extract usable streams.

The webpage being accessible is therefore only the first part of the process.

"The site is supported, but one particular video says unsupported format."

This is entirely possible.

A supported platform can contain:

public videos private videos restricted videos unusual media structures videos with different stream combinations items affected by a platform-side change

The extractor works at the level of the specific media item, not merely the website's name.

"MP4 is supported, but the video still says unsupported format."

Remember:

MP4 is a container, not a universal codec guarantee.

An MP4 can contain different video and audio codecs.

The container, codec, codec profile, available streams, and output requirements all matter.

MDN documents multiple codec/container combinations, including H.264, HEVC, AV1, and VP9 across different containers.

"Changing .webm to .mp4 did not work."

That is expected.

Renaming:

movie.webm

to:

movie.mp4

does not convert the media.

The underlying container structure and encoded streams remain what they were.

A real remux or transcode operation has to process the media.

"The video works on my phone, but the downloader cannot process it."

Again, playback and extraction are different.

Your phone's media stack may be able to decode and play the stream after the platform's own playback system delivers it.

That does not mean an extraction engine can discover, retrieve, combine, and package those streams in the same way.

"The source requires login or private access."

This is an access issue, not simply a format issue.

If the content is private or requires an account, do not treat the problem as something to solve by changing codecs or repeatedly retrying.

MediaFetches specifically recognizes private, members-only, login-required, age-restricted, and similar conditions separately during extraction.

Do not attempt to bypass those restrictions.

"The content is DRM-protected."

DRM is different from an ordinary unsupported codec.

DRM is an access-control/protection system designed to restrict how protected media is accessed or used.

If a source is DRM-protected, changing MP4 to WebM, changing the quality, or renaming an extension does not solve the underlying access-control issue.

Do not attempt to bypass DRM.

When Changing Quality Helps — and When It Does Not

Changing quality is reasonable when MediaFetches successfully reads the source and shows several available options.

For example:

1080p available → 720p available

If 1080p fails but 720p succeeds, the issue may be associated with the higher-quality representation.

But quality changes are not a universal solution.

They are unlikely to fix:

an unsupported website an invalid URL a broken extractor a private video a members-only video a DRM-protected stream a source with no usable media formats a platform-side extraction change

A useful rule is:

If MediaFetches can see the source and offers alternative formats, trying another available quality is reasonable. If MediaFetches cannot identify the source or media at all, changing quality usually isn't addressing the real problem.

Unsupported Format vs Temporary Extraction Problem

These two situations can look almost identical from the user's perspective.

Temporary extraction problem

The source normally works, but:

the platform recently changed something yt-dlp is outdated the extractor temporarily fails the source response is temporarily unusual

An update may fix this.

Genuine capability limitation

The source may simply not be supported by the current extraction pipeline.

No amount of changing:

filename extensions video quality browser phone screen resolution

will create an extractor that does not exist.

This distinction is important because it prevents users from wasting time on settings that cannot affect the underlying problem.

When You Should Stop Troubleshooting

Stop changing settings when the evidence points clearly to a capability or access problem.

For example:

Stop if the source is private

You cannot solve a private-access requirement by changing MP4 to WebM.

Stop if the content is DRM-protected

Do not attempt to bypass the protection.

Stop if the platform is genuinely unsupported

Changing resolution does not add platform support.

Stop if no usable media formats are exposed

There may simply be nothing suitable for the current extraction pipeline to download.

Stop if multiple quality options all fail in the same way

At that point, the problem may be source/extractor related rather than a single quality selection.

Wait for an extractor update when appropriate

If the source recently changed and yt-dlp is behind, an extractor update may be the correct fix.

Final Checklist

When MediaFetches reports an unsupported-source or unsupported-format type problem, work through this list:

Read the exact error message. Check that the URL is valid. Make sure the content is public and accessible. Check whether the platform is generally supported. Remember that platform support does not guarantee every individual URL. Check whether MediaFetches can actually read the source. Look at the qualities the source exposes. Try another available quality only when the source is already being read. Remember that container and codec are different things. Remember that MP4 does not identify every codec inside an MP4 file. Consider separate video and audio streams. Consider whether the extractor may need an update. Do not rename file extensions as a substitute for conversion. Do not treat private, login-required, paywalled, or DRM-protected content as an ordinary format problem. Accept that some sources are simply outside the current capability of the downloader.

The most useful way to think about the problem is:

URL → Source → Media streams → Container/codec → Extractor → Access

Find the first layer that fails.

That tells you whether the appropriate response is to:

correct the URL choose another available quality wait for an extractor update try another supported public source or stop because there is no user-side fix.

An "unsupported format" message is therefore not always telling you that the video file itself is bad. And an "unsupported source" message is not always telling you that the entire platform is impossible to use.

First identify whether the problem is the source, the available media formats, the codec/container combination, the extractor, or an access restriction. Only then decide whether another quality, another source, an update, or simply no action is appropriate.

Related MediaFetches guides

For related guidance, see MP4 vs WebM guide and audio and video merging guide.