Why is my video sideways?

Your phone did not rotate anything

The camera sensor is landscape-shaped, and it stays that way no matter how you hold the device. So when you record standing up, the frames are still written as landscape pictures — and alongside them the file carries a small 3×3 matrix in the track header saying "turn this a quarter turn before you draw it".

Your phone's own player reads that matrix, applies it, and shows you a portrait video. As far as you can tell, the video is portrait. Hand the same file to something that ignores the matrix and it draws exactly what is stored: a landscape picture, lying on its side.

This is why it looks fine in one place and wrong in another

Nothing about the picture changed between the two programs. One of them honoured the note and the other did not, and both were technically reading the file correctly.

Which means "it looks fine on my phone" is not evidence that the file is fine. It is evidence that your phone reads rotation flags — something you already knew.

We got this wrong ourselves

For a while our video tools did not read the matrix at all. On 2026-07-27 we measured it properly and found that four tools — convert, trim, compress and GIF — all produced sideways output from portrait input. Nobody had reported it and every test was green.

The reason it stayed hidden is worth more than the bug. Every video sample we had was landscape, so the rotation path had never once been exercised. It was not a defect that appeared; it was a hole in the sample set that had been there from the start.

The fix came with four files of the same footage written at 0, 90, 180 and 270 degrees, so orientation is the only thing that differs between them. That is the kind of sample that makes an entire category of error impossible to miss.

Size does not prove orientation

This trap is easy to fall into. A 180-degree rotation leaves the width and height completely unchanged, and 90 and 270 swap them in exactly the same way — so checking the dimensions passes happily for a video that comes out upside down, or turned the wrong way entirely.

The only thing that separates them is comparing the actual picture. And each result has to be checked against its own source: we briefly assumed our four samples were the same video, when in fact they were the same stored pixels with different flags, which makes comparing the outputs to each other meaningless.

Fixing it depends on where the video is going

If the output is MP4, the note can be rewritten. The pixels stay exactly as they are and only the matrix changes — which is also the only option available on paths that never decode anything in the first place, like trimming or a container swap.

If the output is WebM or GIF, that route is closed. Rotation in Matroska is supported unevenly across players, and GIF has no concept of it at all. There the picture genuinely has to be turned and baked in, which means re-drawing every frame.

So "rotate the video" is two different operations depending on the destination, and picking the wrong one gives you a file that looks correct in your player and wrong everywhere else — the exact problem you were trying to solve.

What to check

A short list that covers almost every case:

• Right on the phone, sideways after uploading → a rotation flag being ignored, not a broken file.
• The dimensions look backwards → you are being shown the stored size rather than the display size.
• Heading to MP4 → the flag can be rewritten, pixels untouched, quality unchanged.
• Heading to WebM or GIF → the frames must be re-drawn, so expect a re-encode.
• Testing whether a fix worked → compare frames. Dimensions cannot tell 180 degrees from correct.