Why Does a Video Download Work on One Device but Not Another?

First, Decide What “Works” Actually Means

When someone says:

“The video works on my laptop but not my phone.”

there are actually several possible meanings.

Maybe the laptop completed the entire download while the phone could not save the file.

Maybe both devices downloaded the file successfully, but only the laptop can play it.

Maybe the file itself is fine and the real difference is that the laptop was on Wi-Fi while the phone was using cellular data.

These are different problems.

A useful model is:

MediaFetches server

↓

Network

↓

Browser or app

↓

Device storage

↓

Media player / decoder

A problem at any layer can produce the same vague symptom: “It doesn't work on this device.”

The server prepared the file

The first question is whether MediaFetches successfully created the finished file.

If the MediaFetches job reaches:

Ready to save

then server-side preparation has completed.

That is different from a job that remains in:

queued preparing downloading processing failed

The current MediaFetches job API explicitly distinguishes these stages.

The device saved the file

A server can successfully prepare a file while the receiving device fails to save it.

Examples include:

insufficient local storage browser download restrictions interrupted transfer unavailable Downloads folder local permission problem device-specific file handling

That is a file-delivery or saving problem, not necessarily a MediaFetches extraction problem.

The device can play the file

A file can also be saved successfully but fail during playback.

For example:

server: successful

download: successful

file exists: yes

playback: no

That points toward:

codec support container support hardware decoding media-player support incomplete/corrupt output

This distinction is essential.

A download can be technically successful while the playback environment is incompatible.

The Five Layers That Can Cause Device-Specific Problems

MediaFetches server

MediaFetches prepares the media on the server before the finished file is delivered.

The server chooses the available source quality and processes the resulting media according to the job's format-selection logic.

Importantly, I found no User-Agent-based format selection in the current job creation or finished-file delivery path.

For a given job, the same stored finished file is served from:

/api/jobs/:id/file

The server does not appear to inspect whether the client is Windows, Android, iPhone, Chrome, or Safari and then secretly choose a different video.

That means a genuine device-specific result is often occurring after MediaFetches has prepared the file.

Network connection

Two devices can have completely different network paths.

A laptop might use:

home Wi-Fi

while a phone uses:

mobile data

or another Wi-Fi network.

Even when both devices are connected to the internet, they may experience different:

bandwidth latency packet loss DNS resolution routing VPN configuration proxy settings firewall policies

So:

different device

does not necessarily mean:

different device problem

It may actually be:

different network problem

Browser or app

The browser is responsible for handling the final download interaction.

MediaFetches' web client deliberately gives the browser a direct file URL rather than downloading the entire file into a JavaScript Blob.

The current web client creates an <a> element, assigns the finished file URL, sets its download value, and lets the browser handle the transfer.

That matters because browser download behavior varies by browser, user settings, and operating system. MDN notes that browsers may prompt the user, save automatically, or open content in another application depending on the situation. (MDN <a> element)

The HTTP Content-Disposition: attachment header also tells the browser that the resource is intended to be downloaded rather than displayed inline. (MDN Content-Disposition)

Device storage and file system

The phone and computer do not necessarily handle downloaded files in the same way.

Windows, macOS, Android, and iOS have different storage models and different locations where downloaded files are placed.

MediaFetches' native clients make this distinction explicit.

On Android, the native plugin uses Android DownloadManager and places the finished file into the public Downloads directory.

On iOS, the current plugin downloads into the application's Documents directory and then offers the file through the system Share Sheet so the user can choose where to keep or open it.

The browser version, meanwhile, delegates saving to the browser.

So there are genuinely different file-saving paths even though MediaFetches uses the same backend.

Media player and decoder

After the file is successfully saved, another system becomes responsible for playback.

That may be:

the browser the operating system's built-in player a dedicated media app an editing program another application

Playback depends on whether that software can understand the container and the codecs inside it, and whether the device has an appropriate decoder path.

MDN describes a codec as the algorithm used to encode/decode media, while a container packages one or more encoded media streams and metadata. (MDN video processing concepts, MDN media containers)

Why the Same Download Can Behave Differently on Different Devices

Different browsers

Chrome, Firefox, Edge, and Safari share many modern media capabilities, but their exact support and integration with the operating system can differ.

MDN's current codec documentation shows that codec support is not simply a property of the filename extension; browser support also depends on the particular codec and media configuration. (MDN Web video codec guide)

Browser download handling is also separate from media playback.

A browser may download a file correctly while its built-in player cannot play that file.

Or the browser may download it successfully while another browser handles the download differently because of user settings or security policies.

Different operating systems

Windows, macOS, Android, and iOS do not have identical media stacks.

For example, Microsoft documents that some Windows codec support depends on optional codec components, and that AV1 and HEVC behavior can depend on the device and decoder path. (Microsoft supported codecs)

Android similarly documents different codec and container support across versions and devices. Its current media-format documentation includes H.264, HEVC, VP9, and AV1 with different version/device requirements. (Android supported media formats)

This does not mean “Android supports X” or “Windows cannot play Y” in every case.

It means the actual playback environment matters.

Different storage conditions

One device can have plenty of free space while another is almost full.

That can produce:

Laptop: download succeeds

Phone: download fails while saving

without any difference in the server-generated video.

The same applies to removable storage, unavailable Downloads directories, filesystem restrictions, or mobile operating-system storage rules.

Different codec support

Two devices can both recognize:

MP4

but one may support the codec inside that MP4 while the other does not.

This is one of the most important lessons in the entire article.

Different hardware decoding

Decoding a video can be handled by software, hardware, or a combination of both.

A device may have hardware acceleration for one codec/profile and not another.

Microsoft's current Edge troubleshooting documentation explicitly recommends checking hardware-acceleration information because codec playback can depend on the available decoder path and GPU. (Microsoft Edge video playback troubleshooting)

MDN also documents hardware-dependent codec support for some formats. (MDN video codec guide)

This is why two devices with similar-looking specifications can still produce different playback results.

Different network conditions

The phone may not actually be testing the same thing as the laptop.

For example:

Laptop → home Wi-Fi → MediaFetches

while:

Phone → cellular network → MediaFetches

If the phone fails but works immediately when connected to the same Wi-Fi as the laptop, the problem may have followed the network rather than the device.

Different file handling

The final file can be handed to the operating system differently.

MediaFetches' current clients illustrate this:

Web

Browser handles the file.

Android

DownloadManager saves it into public Downloads.

iOS

URLSession downloads it into the app's Documents directory, then the Share Sheet allows the user to move/open it.

That means Android and iOS can legitimately behave differently even when they receive the same MediaFetches file URL.

Download Compatibility vs Playback Compatibility

These are often confused.

Download compatibility

The question is:

Can this device successfully receive and save the file?

Problems here include:

network interruption browser restrictions insufficient storage unavailable download destination permission issues transfer errors Playback compatibility

The question is:

Can this device decode and play the file after it has been saved?

Problems here include:

unsupported codec unsupported container unsupported profile/level hardware decoder limitations media-player limitations corrupt/incomplete file

You can therefore have:

successful download + failed playback

without any contradiction.

Codec and Container Differences Between Devices

The basic rule is:

Container ≠ Codec

MDN explains that the container packages media streams while codecs encode and decode the actual audio and video data. (MDN Media Containers)

MP4

MP4 is a container family based on ISO Base Media File Format.

It commonly contains H.264 video with AAC audio, but MP4 can contain other codec combinations too.

So:

“.mp4” does not tell you the complete codec story.

MDN explicitly notes that the MIME type for MP4 can be combined with a codecs parameter to specify the particular codecs used inside the container. (MDN Media Containers)

WebM

WebM is a web-oriented container commonly associated with VP8, VP9, AV1, Opus, and Vorbis.

Modern browsers support WebM broadly, but the precise codec and device support still matter.

WebKit states that Safari 17.4 added full WebM support on iOS and iPadOS, while desktop macOS support had already been expanded earlier. (WebKit Safari 17.4)

That is a good example of why a statement like “iPhones don't support WebM” would now be outdated and too broad.

H.264

H.264/AVC remains one of the most widely supported video codecs.

MDN's current video-codec documentation lists H.264 support across modern browsers, while also noting that Firefox relies partly on operating-system codec infrastructure. (MDN Web Video Codec Guide)

That still does not mean every H.264 stream is identical.

Profile, level, pixel format, HDR characteristics, and other properties can matter.

HEVC/H.265

HEVC can be well supported on many modern devices, but compatibility is more conditional.

MDN's current documentation shows platform-dependent browser support for HEVC, and Microsoft documents that Windows playback can depend on the HEVC extension and decoder path. (MDN HEVC, Microsoft supported codecs)

So:

MP4 + HEVC

is not equivalent to:

MP4 + H.264

from a compatibility perspective.

VP9

VP9 is widely used for web video and is commonly associated with WebM.

Android lists VP9 among its supported video codecs, with support depending on device/version capabilities. (Android supported media formats)

AV1

AV1 is a newer codec designed for efficient compression.

Support is now widespread enough to be useful, but it still varies by browser, operating system, device, and hardware.

MDN's current documentation shows broad browser support while also identifying device-specific limitations, including hardware-dependent support in some environments. (MDN AV1)

Android's documentation lists AV1 decoder support beginning at Android 10, with mandatory encoder/decoder support from Android 14 onward for Android's media framework. (Android supported media formats)

The practical lesson is not “avoid AV1.”

It is:

Know what the target device can actually decode.

Why a Video May Download on One Device but Not Another Browser download behavior

MediaFetches' web client uses the browser's download mechanism rather than buffering the entire finished file into JavaScript memory.

That reduces the amount of page memory required for a large file.

The browser is then responsible for its own download UI, file handling, and local save behavior.

MDN notes that browser treatment of downloads can vary depending on browser and user settings. (MDN <a>)

Storage or permission problem

If the server reaches Ready but one device cannot save the file, compare:

free storage download destination permissions operating-system restrictions

On Android, the native MediaFetches plugin explicitly maps Android DownloadManager's insufficient-space condition to:

“There is not enough free space on your device.”

It also separately handles cases where the Downloads location is unavailable.

On older Android versions, the plugin requests storage permission where required.

On iOS, the plugin moves the downloaded temporary URL into the app's Documents directory and reports a saving error if that move fails.

These are local device conditions rather than source-extraction errors.

Network interruption

If the file cannot be retrieved successfully from MediaFetches, the device/network path may be responsible.

Test:

same device + different network

This is one of the fastest ways to separate device problems from network problems.

Browser or OS restrictions

Some browser and operating-system environments impose different policies around downloads, file access, background activity, or the location where files can be saved.

That can create:

same URL + same server + different result

without requiring a different server response.

Device-specific software problem

A browser version, media player, operating-system component, or device software can be outdated or have a compatibility problem.

Update the affected software when appropriate, but first identify whether the problem is downloading or playback.

Why a Downloaded Video May Play on One Device but Not Another Unsupported codec

The most common conceptual explanation is:

same container + different codec support

For example, two .mp4 files may use different video codecs or profiles.

Unsupported container

The receiving player may not support the container itself.

Windows' current media documentation demonstrates that container/codec combinations can differ in support, and Microsoft specifically notes that not all media codecs are natively supported in every playback configuration. (Microsoft supported codecs)

Hardware decoding limitations

A device may theoretically have software support for a codec but perform poorly or fail under certain demanding configurations because the available hardware decoder does not support them.

This is one reason “the phone is newer” is not, by itself, a sufficient compatibility test.

Media player limitations

The built-in player is not the same thing as the operating system's entire media capability.

One application may support a file that another cannot.

So test:

same file + different player

This helps distinguish a file problem from a player limitation.

Corrupted or incomplete file

Do not jump to codec explanations too quickly.

A file that was interrupted may be incomplete.

If the laptop plays a file perfectly but the phone received only a partial copy, the codec may be innocent.

Compare the file size on both devices.

If the files differ in size, you are not actually testing the same completed file.

How MediaFetches Fits Into the Process What happens on the server

The current MediaFetches workflow prepares the media as a server-side job.

Conceptually:

URL

↓

MediaFetches job

↓

source extraction

↓

selected media formats

↓

download

↓

processing if required

↓

finished file

↓

Ready

The finished file is then exposed through the job's file endpoint.

What the browser or native app receives

The current endpoint sends:

Content-Type Content-Disposition Content-Length Accept-Ranges Cache-Control X-Content-Type-Options

For partial range responses it also sends:

Content-Range

The endpoint does not currently send ETag or Last-Modified.

Those details matter because clients can use HTTP headers when deciding how to save and resume transfers.

MDN explains the role of Content-Disposition in telling clients whether content should be displayed inline or treated as an attachment. (MDN Content-Disposition)

What MediaFetches does and does not control

MediaFetches controls the preparation and server-side delivery of the finished file.

It does not control:

every browser's download UI the device's available storage every installed media player every hardware decoder every operating-system codec component

This is why a successful MediaFetches job is not a universal guarantee that every device will play the resulting file.

A Practical Device-to-Device Troubleshooting Test

Use this sequence when one device works and another does not.

Step 1: Compare the exact URL

Make sure both devices are testing the same source URL.

Do not compare a copied shortened URL on one device with a different final URL on another.

Step 2: Compare the browser

Try the same current browser on both devices when practical.

This removes one variable.

For example:

Chrome on laptop

versus:

Chrome on phone

is easier to compare than Chrome on one device versus Safari on another.

Step 3: Compare the network

Test:

same device + different network

Then, where practical:

different device + same network

This produces a very useful diagnostic matrix.

If the problem follows the network, investigate the network.

If it follows the device, investigate the device.

Step 4: Compare available storage

Check whether the failing device has enough free space.

For a large video, do not wait for the storage warning to appear at the end.

Step 5: Check whether the file actually exists

Open the device's Downloads or Files location.

Do not diagnose playback until you know the file was actually saved.

Step 6: Check the file size

Compare the file size on both devices.

If one copy is 700 MB and the other is 120 MB, you are not testing the same completed file.

Step 7: Try another browser

If the file saves in one browser but not another on the same device, the browser becomes a stronger suspect.

MDN notes that download behavior can differ between browsers and user settings. (MDN <a>)

Step 8: Test the finished file on both devices

Once you have the same completed file, test it on both devices.

This isolates playback from downloading.

Step 9: Check codec and container compatibility

If the same completed file exists on both devices but only one can play it, investigate:

container → video codec → audio codec → decoder/player

Do not assume .mp4 is enough information.

Step 10: Identify the first layer that differs

At the end ask:

Did the problem follow the device?

The browser?

The network?

The file?

Or MediaFetches itself?

That answer is much more valuable than simply saying:

“It doesn't work on my phone.”

Common Device-Specific Scenarios Works on Windows but not Android

First determine whether Android:

successfully receives the file successfully saves it can play it

If saving fails, investigate storage/network/download handling.

If saving succeeds but playback fails, investigate codec/container/player support.

Android's official format documentation is the correct place to verify codec/container support rather than relying on a blanket statement such as “Android cannot play this format.” (Android supported media formats)

Works on Android but not iPhone or iPad

Check whether:

both devices received the same completed file the iPhone/iPad successfully saved it the player used by iOS supports its encoding the browser/app path differs

Modern iOS/iPadOS has broader WebM support than older releases; WebKit documented full WebM support arriving in iOS/iPadOS 17.4. (WebKit Safari 17.4)

So version matters.

Works in Chrome but not another browser

Try the same file directly.

If both browsers can access the file but only one downloads it correctly, investigate browser download behavior.

If both download the same file but only one plays it, investigate media support rather than the download.

Downloads successfully but will not play

This is usually a playback compatibility question first.

Check:

file completeness extension container codec media player hardware decoder

Do not immediately download the file again if the exact same bytes are already present.

Works on Wi-Fi but not mobile data

That strongly suggests a network-path difference.

Check:

mobile signal mobile-data restrictions VPN proxy carrier/network conditions

The device may be perfectly capable of downloading the file.

Works on one network but not another

Again, treat the network as the variable.

A corporate, school, public, or mobile network can have different routing or security controls from a home connection.

Do not automatically replace the browser or media player when the same device works normally on another network.

How to Avoid Device-Specific Download Problems

You cannot eliminate every compatibility difference, but you can reduce the number of variables.

Keep the browser current

Use a current version of your normal browser.

Keep the operating system current

Codec and media-stack support can change through OS updates.

Check storage before large downloads

A nearly full device is a poor environment for a large file transfer.

Keep a known-good copy

If a file plays correctly on one device, keep that completed copy while testing the other.

This prevents accidentally replacing a good file with an incomplete one during troubleshooting.

Use a suitable media player

If the file is complete but the built-in player cannot decode it, another compatible player may solve the playback problem.

That does not mean the original downloader was broken.

Choose a broadly compatible source representation when you control the choice

When multiple source qualities/formats are available, compatibility can be more important than simply choosing the largest file.

This is especially true when the file must move between different devices.

Avoid assuming the file extension tells the whole story

.mp4 and .webm are container-level clues, not complete descriptions of the encoded media.

What MediaFetches Cannot Guarantee Across Every Device

MediaFetches can prepare and deliver a finished media file, but it cannot guarantee that every combination of:

browser + operating system + codec + decoder + media player + device

will behave identically.

The current project also does not expose a universal compatibility selector that lets users choose:

codec decoder hardware acceleration playback application operating-system media component

It selects the source formats internally and produces the configured output path.

Once the file is handed to the device, the remaining compatibility chain is largely outside MediaFetches' control.

The native apps are also intentionally different at the final save stage:

Android → DownloadManager → public Downloads

iOS → URLSessionDownloadTask → app Documents → Share Sheet

Web → browser download

That means some device differences are built into the client environment itself.

Common Questions Why does the same video download on my laptop but not my phone?

First determine whether the phone failed to download, save, or play the file.

Then compare network, browser, storage, and device conditions.

The word “download” can hide several different failure stages.

Why does the video download but not play on another device?

The file may be complete but use a codec, container, profile, level, audio track, or other configuration the second device/player cannot decode.

Try the same completed file with another compatible player before assuming the download itself was bad.

Why does MP4 work on one device but not another?

Because MP4 is a container, not a single codec.

Different MP4 files can contain different video/audio encodings.

MDN explicitly documents codec information as a separate part of identifying an MP4 media type. (MDN Media Containers)

Can a browser cause a download to fail?

Yes.

Browser download behavior, settings, permissions, storage handling, and security policies can affect how a file is saved.

The important diagnostic step is to compare browsers on the same device.

Can storage cause only one device to fail?

Absolutely.

One device can have enough free space while another is almost full.

That is a local device condition, not necessarily a server problem.

Does MediaFetches control video playback after download?

No.

MediaFetches controls server-side media preparation and file delivery.

After the file is saved, playback depends on the browser, operating system, media player, codec support, and device decoder.

Should I use the same browser on both devices?

It can be useful for troubleshooting because it removes one variable.

Once the problem is understood, there is no general requirement that every device use the same browser.

Why does the same URL behave differently on different networks?

Because the network path is part of the system.

Wi-Fi, cellular, VPNs, proxies, DNS resolvers, firewalls, routing, congestion, and network policies can differ.

Test the same device on two networks to see whether the problem follows the connection.

Related MediaFetches guides

For related guidance, see where downloaded videos go and MP4 vs WebM guide.

Final Takeaway

A video download can behave differently on different devices because “download” is not one single operation.

The complete path is closer to:

MediaFetches server

↓ network ↓ browser or app ↓ device storage ↓ media player ↓ decoder

A failure at any layer can look like a device problem.

The most useful troubleshooting method is therefore:

Does MediaFetches prepare the file?

↓

Can the device save it?

↓

Can the device play it?

Once those questions are separated, the diagnosis becomes much easier.

If the file is not produced, investigate MediaFetches or the source.

If the file is produced but one device cannot save it, investigate storage, browser behavior, permissions, or the network.

If the exact same completed file exists on both devices but only one plays it, investigate the container, codec, decoder, and media player.

And if one device works only on Wi-Fi while another test uses mobile data, remember that you may not be comparing devices at all.

You may be comparing networks.

The central rule is simple:

When the same video behaves differently on different devices, find the first layer where the behavior changes.

That tells you whether the problem follows the device, browser, network, file, or MediaFetches server—and prevents you from changing settings that were never responsible in the first place.