Troubleshooting
Works on the Computer, Fails on the Phone
The same link, the same tool, two different results — and the phone is almost always the one with the extra rule. Four causes cover nearly everything: a permission prompt you missed, the browser suspending the download when you switched apps, storage running out silently, or the video playing instead of saving. None of them happens on a computer.
Why phones are stricter
Desktop browsers assume you know what you are doing. Click a download, it saves, and the browser tells you afterwards. Phones invert that: every download is a request that has to be justified.
The reasons are reasonable. Storage is limited and not easily expanded, battery is finite, connections are metered, and the operating system actively manages what runs. Each of those produces a rule that has no desktop equivalent.
| Behaviour | Desktop | Phone |
|---|---|---|
| Permission to download | Never asked | Asked once per site |
| Download in a background tab | Continues | May be suspended |
| Video link opened directly | Downloads | Plays in a player |
| Out of storage | Clear error | Often silent |
| Several downloads at once | Fine | Blocked after the first |
The permission prompt nobody sees
The most common cause on iPhone and iPad, and it is genuinely easy to miss.
The first time a website downloads anything, Safari asks whether to allow downloads from that site. The prompt is small, appears at the top of the screen, and fades after a few seconds. Miss it and nothing downloads, with no error and no explanation.
Tap Allow and it is remembered. If you dismissed it, revisiting the site triggers it again, or on a Mac you can set it per site under Safari's website settings.
Android's equivalent is gentler — Chrome generally downloads without asking — but some manufacturers add their own confirmation, and a few restrict downloads on metered connections by default.
Background suspension
The cause that produces the most confusing symptom: a download that starts, appears to be working, and never finishes.
Phones suspend background activity aggressively to save battery. Switch apps, lock the screen, or let the display time out, and a download in a browser tab can slow to nothing or stop entirely. You return to a partial file or none at all.
The fix is unsatisfying and reliable: keep the browser in front until the download finishes. For a large file, temporarily increase the auto-lock delay in settings — a 70 MB video over a slow connection can easily outlast a thirty-second screen timeout.
Android varies more than iOS here because manufacturers layer their own battery management on top. If downloads consistently die the moment you put the phone down, that is a system setting rather than anything a website controls.
The video that plays instead of saving
Specific to phones, and the failure mode that leaves people most certain the tool is broken.
Mobile browsers treat a link that returns video as something to play. Tap it and the video opens full-screen in the built-in player — which has no save button. You watch it, close the tab, and have nothing.
On a desktop the same link downloads, because desktop browsers default to saving what they cannot display inline. The identical link behaves oppositely on the two devices.
The fix belongs to the site rather than to you: a file sent with the right header is saved rather than played. If a tool hands you a direct video link and your phone plays it, that tool has not handled the mobile case — which is worth knowing, because it will do the same thing every time.
Storage and the silent failure
Phones abandon downloads when space runs out, usually without a message.
The requirement is larger than the file. Some browsers write a temporary copy and move it at the end, so briefly two copies exist — a 70 MB video wants comfortably more than 70 MB free.
The tell is that small files work and large ones do not while the connection is fine. That pattern is storage, not the tool — what is actually filling the phone is covered here.
Desktops have far more space and report the failure clearly when it happens, which is why this cause is effectively phone-only.
Working through it
- Watch the top of the screen after tapping save, for a permission prompt.
- Keep the browser in front until the download completes.
- Check free storage — twice the file size is a safe margin.
- Try a smaller quality. Faster, less exposed to everything above, and hard to distinguish on a phone screen.
- Look in the right place. On iPhone it is the Files app, not Photos — a download that worked can look like one that did not.
Step five closes a surprising share of these. The download succeeded; the file is in Files, and the person is looking in Photos.
The bug that only existed on phones
We shipped this failure ourselves, and it is the clearest example of why mobile deserves its own article rather than a footnote.
The original design was the obvious one: give the browser a direct link to the video and open it in a new tab. No traffic through our servers, no cost, and it works correctly on a desktop — the browser downloads what it is given.
On a phone it was a dead end. Mobile Safari sees a link returning video and does what it considers helpful: plays it full-screen in the built-in player. That player has no save button. People watched their video, closed the tab, and had nothing — a download that felt like it worked and left no file. The owner found it himself on 29 July 2026, and the code still carries a comment with the date, because the cause is not obvious enough to leave unexplained.
The fix is a single header: a response marked as an attachment tells the browser to save rather than display. But we cannot attach a header to another server's response, and a page cannot fetch the file and re-serve it either — platform CDNs send no CORS headers, so the browser refuses before the request starts. That left one route: pass the file through us.
It costs us bandwidth on every single download, which is a real and permanent expense we would rather not carry. We carry it because the alternative is a product that quietly fails on the most common device our visitors use. The file is streamed in 64 KB chunks and never written to our disk, so nothing accumulates and memory stays flat regardless of size.
What we still cannot fix are the platform's own rules. Safari will not let a page save several files in sequence without confirming each one, and it treats rapid repeats as something to block — so there is no ‘save all’ on iPhone, and anything promising one is either not doing it or will stop working at the next Safari update.
Frequently asked questions
Why does a download work on my computer but not my phone?
Phones add rules desktops do not have: a permission prompt, background suspension, silent storage failures, and video links that play instead of saving.
Why did nothing happen when I tapped save on iPhone?
Almost always the Safari permission prompt, which appears briefly at the top of the screen and fades. Revisit the site and watch for it.
Why does my download stop when I switch apps?
Phones suspend background activity to save battery. Keep the browser in front until the download finishes.
Why did the video play instead of downloading?
Mobile browsers play video links in a built-in player with no save button. A file sent as an attachment is saved instead — that is the site's responsibility, not yours.
Why do large files fail while small ones work?
Storage. Phones abandon downloads quietly when space runs out, and the requirement is roughly twice the file size.
Can I download several files at once on a phone?
Not on iPhone. Safari requires confirmation for each download and blocks rapid repeats. Save them one at a time.
VidKeep runs in your browser — paste a link, pick a quality, keep the file. No account, no app.
Open VidKeepLast updated: 2026-08-01. We revise our guides as the platforms change.
