Recipient Can't Download? Fix File Access Issues Fast
Your recipient can't download the file you sent? Troubleshoot common access issues including expired links, password problems, and browser compatibility.
When a recipient says they can't download, ask four questions before anything else: what error message are they seeing, what browser and device are they on, are they on a corporate network or VPN, and was there a password. Most download failures fall into three buckets: the link is expired or malformed (you need to re-upload), the recipient's network is blocking the service (they need to try another network), or the password is wrong or the recipient doesn't have it. Each is a five-minute fix once you know which bucket it's in.
Get the exact error message first
"It doesn't work" is useless. Ask for a screenshot. The difference between "This link has expired" and "Access denied" and "This site can't be reached" is three different fixes. A 30-second screenshot saves an hour of back-and-forth.
If they can see a branded transfer service page (WeTransfer, SwissTransfer, your chosen tool) with any message on it, the network reaches the service and the problem is on the service side. If they see a browser error or a blank "can't connect" page, the problem is their network.
"Link expired": re-upload
Transfer links typically expire between 7 and 30 days after upload. Once expired, the file is deleted server-side and there's no recovery on free tiers. Re-upload, and this time set the maximum retention (30 days on WeTransfer Pro, Smash, SwissTransfer). If you don't have the source file anymore, check your local backups, Time Machine, or wherever you originally exported from.
Before re-uploading, consider whether the recipient will actually download this time. If they sat on the first link for 7 days, a same-duration second link may die too. Extend, or switch to a service with a 30-day default.
"Password required" or password fails
The recipient needs the password and you share it via a second channel. Email is a weak channel because the same mailbox holding the link holds the password; if the inbox leaks, both leak. Use Signal, SMS, WhatsApp, or a voice call.
If they're entering the password and it fails, common causes: extra trailing space (copy-paste issue), case mismatch (passwords are case-sensitive), or they're looking at an old password from a previous transfer. Re-send the password and make sure the format is clean (no auto-capitalisation from their messaging app).
Most services lock out the link after 5 wrong attempts for 15 minutes to prevent brute-force. If the recipient hit that limit, they just need to wait.
Corporate firewall blocking the service
Enterprise networks often categorise file transfer sites as "file sharing / uncategorised" and block them by policy. Symptoms: browser timeout, "this site is blocked by your organisation," or an unexpected captive portal page.
Ask the recipient to try from their phone on cellular (hotspot if needed). If the link works off-corporate network, the firewall is the issue. They need to request an allowlist from IT, or download from home.
This is common with Zscaler, Cisco Umbrella, Palo Alto, and Forcepoint appliances. Some categorise WeTransfer, Smash, and SwissTransfer differently, so a recipient who can't download from one tool might succeed with another. End-to-end encrypted services are sometimes harder to allowlist because IT can't inspect traffic, a known friction point.
Browser compatibility
Most modern transfer services work on Chrome, Firefox, Safari, and Edge on current OS versions. Problems show up on: Internet Explorer (obsolete, doesn't support modern TLS), very old Android browsers (pre-Chrome 80), and some embedded email browsers that open links in-app with stripped functionality.
If the recipient is opening the link from inside Gmail's mobile app's in-app browser, ask them to tap "Open in browser" first. In-app browsers lack some cookie and download capabilities, particularly for services that use the File System Access API for downloads.
iOS Safari handles most services but does have a 15 GB single-download soft cap before it starts aborting. For 10 GB transfers, the recipient should use desktop.
VPN interference
Some recipients run VPNs that route traffic through specific countries. Geo-restricted downloads (rare, but some paid services restrict by region) fail. Some free VPNs also drop long-lived TCP connections, killing downloads at the 5 to 10 minute mark.
If the recipient is on a VPN and the download keeps failing, have them disconnect the VPN, retry, reconnect afterwards. If the transfer service uses end-to-end AES-256-GCM, confidentiality is already handled without needing the VPN during the download.
Antivirus quarantining the file
Some corporate AV (Symantec Endpoint, McAfee, Sophos) inspects downloads and quarantines files matching heuristics, even for clean files. Large archives (.zip, .7z, .rar) trigger this most often. Executables (.exe, .msi, .dmg) almost always do.
Workarounds: rename the archive to a neutral extension (.bin or .dat) before upload, with instructions for the recipient to rename after download. Or switch to a format their AV trusts, like .tar.gz or plain folder structure.
Correct URL, correct encoding
Some email clients break long URLs on soft-wrap, especially if the URL contains underscores or equals signs. Check the URL the recipient is clicking against the one you sent. Common format: https://service.com/share/a1b2c3d4... with a 20 to 40 character token.
If you suspect truncation, send via WhatsApp or Signal. Mobile messaging apps handle long URLs more reliably than email.
Also check capitalisation. Some services' URLs are case-sensitive for the token portion.
Download speed crawls to a halt
Not strictly "can't download" but functionally the same: a 10 GB download at 50 KB/s means 55 hours. Causes: recipient's network is saturated (someone in their house is streaming 4K), they're on a slow ISP (under 10 Mbps downstream), or the transfer service's CDN is serving a distant edge.
Ask the recipient to run a speedtest. If their ISP is fast but the download is slow, try a different DNS on their side (Cloudflare 1.1.1.1 often re-routes to a closer CDN edge).
Tell them to try incognito mode
The fastest diagnostic: "open the link in incognito/private mode." This disables extensions and ignores stored cookies. If it works in incognito, the issue is in their regular browser's cache or extensions. Clear cookies for the transfer service's domain, or disable extensions one at a time.
If incognito fails too, move on to network-level diagnosis.
If the service is the issue, switch
If you keep hitting recipient problems with a particular service (corporate firewalls blocking, in-app browser issues, unclear error pages), switch. A transfer service with clean, descriptive error states makes recipients self-diagnose without pinging you. HexaTransfer shows explicit states on the download page for expired, password-protected, and deleted links, runs on standard HTTPS that corporate firewalls commonly allow, and doesn't require the recipient to create an account or install anything.
Try it at hexatransfer.com — free, no account, 10 GB max.
Send large files securely with end-to-end encryption
Transfer files up to 10 GB for free with end-to-end encryption. No account required. Your files are encrypted in your browser before upload — no one else can read them.
Send a file