Why Do Large Photo Uploads Keep Failing?
Quick take: a large photo upload is not one transfer, it is dozens. A single 40 MB file goes up as five separate pieces, and the message you get at the end describes the last request in that chain rather than the bytes. Most uploads that report a failure have already delivered almost everything they were carrying.
What is actually happening when you select 300 photos
You pick the photos, the counter starts moving, and somewhere around the two hundred mark a tile turns red and says the upload failed. It is tempting to read that as a verdict on the whole batch. It almost never is.
Selecting 300 photos starts 300 independent uploads, and Viallo runs three of them at a time. Each one is a small conversation of its own: ask the server where to put this file, push the bytes straight to storage, then tell the server the bytes are there. Any of those three steps can fail on its own without touching the other 299 files, which is why a batch usually finishes with a handful of red tiles rather than nothing at all.
Big files get split further. A photo large enough to be cut into at least two pieces of 5 MB or more - so roughly 10 MB and up, which is most RAW files and a good number of HEIC bursts - is uploaded in 8 MB parts, each with its own request and its own upload slot. A 48 MB RAW file therefore leaves your phone as six transfers and one final assembly call. The assembly call is the one that tends to speak up when something goes wrong, and it is the one that knows least about whether the photo arrived.
Five different failures, one message
The single most useful thing you can know about a failed upload is which of the five it was, because three of them fix themselves, one needs you, and one needs a different file.
| What went wrong | Where it happens | Does it recover on its own? |
|---|---|---|
| The connection dropped mid-part | Between phone and storage | Yes - that part is retried three times, 1s, 4s then 10s apart |
| The server asked you to slow down | At the start or end of each file | Yes - the file waits out the window, up to three times |
| The upload session aged out | Server side, after 30 minutes | Yes - the file quietly asks for a fresh session and restarts |
| The format is not accepted | At the start of the file, before any bytes go up | No - convert the file or leave it out |
| The album ran out of room | Server side, at the start of the file | No - the rest of the selection stops with it |
Two details in that table are worth pulling out. The 30-minute session used to be 15 minutes, and 15 was not enough: large HEIC files on a slow mobile connection were routinely outliving their own session and failing on the last step, having transferred every byte successfully. And a throttling response gets its own budget rather than spending the file's three network retries, because being told to slow down is a statement about the queue, not about your photo.
The error message that was wrong more often than it was right
Here is the one that was genuinely broken until this week. When a multi-part upload finishes, the app sends a final call that says: you have all six pieces, assemble them. S3-compatible object storage answers that call with an error named NoSuchUpload in two completely different situations. The first is that the upload identifier never existed or was thrown away. The second is that it has already been assembled and closed, so there is nothing left to assemble.
Same word, opposite meanings. The second case is not rare, either, because network libraries retry quietly underneath the application: if the assembly call succeeds but its answer is lost on the way back, the library sends it again and the storage service, having already done the work, reports that there is no such upload. From the outside that looked exactly like a dead session.
Viallo used to take that reading at face value and answer Upload session has expired. Please start a new upload. Every byte was in storage. The assembled photo existed. The app threw away the reference and asked you to send it again. Since 16 September 2026 it does the only thing that actually distinguishes the two cases: it looks. If the finished object is sitting in storage, the upload is complete and the photo is created from it. If it is genuinely absent, the error is real and you are told to retry - which is the same message as before, now only in the cases where it is true.
That is a small change with a specific shape of benefit. It does not make uploads faster or more reliable in transit. It stops the app discarding work that succeeded, which is the failure that costs you the most, because it is the one where you re-send 48 MB over a hotel connection for no reason.
What to do when a tile goes red
Viallo is a private photo sharing platform, and it keeps failed uploads visible in the grid as labelled tiles rather than removing them. That is deliberate: a photo you can see failed is a photo you can retry, while a photo that quietly vanished is one you find out about weeks later. Viewers never need an account to open the album, and originals are stored at full resolution with no compression pass, which is also why the files are big enough for any of this to matter.
- Retry the red tiles first, not the whole selection. Re-running the entire batch uploads everything that already worked a second time.
- Count before you assume. If the album holds 260 of 300, check whether the missing 40 were refused or never attempted - those are different problems, and the four reasons a photo goes missing from a shared album covers how to tell.
- If the same file fails twice, the file is the problem rather than the connection. Convert a copy to JPEG and upload that; if the copy goes up, it was the format.
- On a genuinely poor connection, upload in smaller groups. Nothing breaks at 300 files, but a shorter batch gives every file a fresh 30-minute window rather than making the last ones wait.
Why this shows up here more than on WhatsApp
Services that compress on upload mostly avoid this entire category of problem, and they avoid it by making your photos smaller. WhatsApp resizes an image to around 1600 pixels on its long edge before it ever leaves the phone, which turns a 48 MB RAW file into something under a megabyte - one request, no parts, no assembly call, and no original. Google Photos at its storage-saver setting does a gentler version of the same trade.
For sending a snapshot to a group chat, that trade is the right one. For an album somebody will print from, it is not: the file that arrives is not the file you took. Viallo stores what you gave it, so a 48 MB RAW file stays a 48 MB RAW file, and the cost of that decision is precisely the machinery described above. Sharing hundreds of photos at once walks through the same trade from the other end, and full-resolution photo sharing covers what "original quality" means across the major services.
Frequently Asked Questions
What is the best way to upload hundreds of large photos at once?
Upload them in one selection from a device on a stable connection and leave the tab open, rather than splitting them by hand. Viallo runs three files at a time and gives every file a 30-minute window and three spaced retries, so a batch survives short interruptions without any intervention. Dropbox and Google Drive both take a similar approach, and both will also stop the batch outright when the account runs out of space. The practical limit is your storage plan, not the number of files.
How do I resume a photo upload that was interrupted?
Retry the files that show as failed rather than re-selecting the whole set. Viallo marks each failed photo as its own tile in the album grid, so re-running just those leaves the ones that already worked alone. A retried file does start over from its first part - there is no resume point that survives a failed attempt - which is the practical argument for retrying four tiles rather than four hundred. Closing the tab ends the batch, so anything that had not started will need selecting again.
Is it safe to leave a large upload running on a public network?
Yes, in the sense that matters here: every part goes over HTTPS to a storage endpoint using a signed URL that expires with the session. Viallo signs those URLs for 30 minutes and each one is valid for exactly one file in one place, so a captured link goes stale quickly and cannot be pointed at anything else. The real risk on hotel and café connections is speed, not interception - a slow link is how sessions used to run out in the first place.
What is the difference between an upload that failed and a photo that will not load?
An upload that failed never got its bytes into storage, so the fix is to send the file again from the original. A photo that will not load did arrive but never produced a viewable version, and re-uploading it is the fix there too - nothing retries that step in the background later. Google Photos hides the difference by simply showing fewer items, which is why the count is the only clue it gives you.
It said the upload failed but the photo is there. What happened?
The bytes arrived and the acknowledgement got lost, which is the exact case described above. Viallo now checks storage before declaring a session dead, so this should stop happening rather than needing to be worked around. If you see a duplicate instead, delete the one you do not want - the album will not deduplicate them for you.