What's new: videos that tell you why, and uploads you can watch

Two things shipped since the last update, and they have something in common: both are about removing the moment where you can't tell whether something is broken or just slow.

"Why won't this video play?"

If you've ever sent someone a video off your phone and heard back that it didn't work, this one's for you.

iPhones record in a format called HEVC by default. Safari plays it. Chrome usually plays it. Firefox generally doesn't — and when it can't, it doesn't announce that. The file loads, the duration shows up, the scrubber appears, and then nothing happens. Forever. No error, no message, just a player sitting there.

From the outside that looks identical to a slow connection, which is exactly why it's so annoying. The person who sent the video knows it works, because it works for them. The person who received it is staring at a spinner. Neither of them can tell what's wrong.

So now the page asks. Before anyone presses play, we ask the browser directly whether it can decode the file — not "which browser is this" and a lookup table, but the actual engine, in that moment. If the answer is a definite no, the page says so up front and offers the download instead. If the browser turns out to be wrong and it plays anyway, the message quietly retracts itself.

There's a second failure worth mentioning, because it's a strange one: sometimes a video starts, audio plays, and the picture just freezes. The clock keeps moving, so nothing looks stuck, but you're listening to a still image. We now spot that too — by watching whether frames are actually being drawn, rather than whether time is passing — and say plainly that it's a limitation of that browser, not a problem with your file. Because it isn't your file. Downloading always works.

We also flag things on the way in. Drop a HEIC photo straight off an iPhone into an upload and you'll be told that most browsers won't display it. And if your own browser can't read a file well enough for us to make a thumbnail, we mention it — that's usually a reliable sign nobody else will get a preview either.

Nothing is blocked. Every one of these files uploads, downloads and shares exactly as before. You just get to know in advance instead of finding out from a confused message three days later.

Uploads go one at a time now

We used to send three files at once. It seemed faster. It mostly wasn't.

Three simultaneous transfers share one connection, and on anything short of a very good line they spend their time competing rather than finishing. Worse, when something went wrong you'd get a failure and three half-finished progress bars, and working out which file actually broke was your problem.

So they queue. One finishes, the next starts. On a fast connection you'll lose a few seconds. On hotel wifi, a train, or a phone with two bars, it's steadier — and if a file does fail, it's obvious which one and why.

And a progress list you can read

The old view was a grid of small square thumbnails, four across, each with just enough room for a word like "Done". Fine for three files. Not fine for thirty.

Now every file gets its own line: a thumbnail big enough to recognise, the whole filename rather than the first twelve characters of it, and a progress bar running the width of the row with the byte count underneath. The file currently uploading fills across; the ones waiting sit quietly with no bar at all, because an empty bar on every row looks like everything has stalled at zero.

If a file fails, the reason is right there on its row — "File too large for your plan", say — rather than collected into a summary you read after the fact.

It's a small change and it wasn't strictly broken before. But you spend the whole upload looking at this list, and it should be worth looking at.