Why Videos Turn Sideways After Converting

If a video plays right-side-up in one app and sideways in another, the video itself is fine — a small piece of instructions attached to it got lost. Phones and cameras usually record the actual video frames in landscape, no matter which way you were holding the device. Instead of rotating the pixels, the camera writes a "rotate this on playback" flag into the file. Players that read that flag show it correctly; players (or converters) that ignore it show the raw landscape frames, which looks sideways or upside down. This is extremely common with MOV and MP4 files specifically, because that's exactly where the flag lives.

MOV and MP4 are container formats, and inside that container each video track carries a small transformation matrix — a set of numbers that can tell a player "rotate this track 90, 180, or 270 degrees before displaying it." This is sometimes called a rotation atom or display matrix. It's not baked into the pixels; it's a separate instruction sitting alongside the encoded video data. QuickTime, VLC, and most modern browsers read this matrix automatically and rotate the frame for you on the fly, so you never notice it's there. The video data on disk is still landscape — only the display instruction says otherwise.

The problem shows up during conversion because not every tool treats that matrix the same way. Some converters copy the raw video stream — the actual encoded frames — without carrying the rotation matrix along with it, or without correctly re-applying it to the new container. The result is a file whose pixels are still stored landscape but whose "please rotate me" instruction is now missing or wrong. It plays back exactly as recorded, sideways, in any player that isn't independently guessing at the intended orientation. This isn't corruption — the frames are intact — it's a metadata handoff that didn't happen.

If you have a copy of ffmpeg installed and you're comfortable with a command line, there are two ways to fix a sideways file. If the original rotation flag just needs to be set (or reset) on the container without touching the video data, this is fast: `ffmpeg -i input.mov -metadata:s:v:0 rotate=90 output.mp4` — adjust `90` to `180` or `270` as needed. If a player is still ignoring the flag, you can physically bake the rotation into the pixels instead with a transpose filter, for example `ffmpeg -i input.mp4 -vf "transpose=1" output.mp4`, which re-encodes the video so it's correctly oriented for every player, flag or no flag.

If ffmpeg isn't an option, the simplest non-technical fix is to open the sideways file in a video editor that lets you visually rotate it 90, 180, or 270 degrees and save a new copy — this bakes the correct orientation into the video itself, so playback no longer depends on any app reading a flag correctly. Most phone photo apps (iOS Photos, Google Photos) and basic desktop video editors include a rotate option for exactly this. It's an extra step after the fact, but it's reliable across every player afterward, which a metadata flag alone isn't.

There's no universal setting on your phone that prevents this, since the rotation flag is standard behavior, not a bug to disable. What helps is being deliberate about the tools in the chain: use a converter that's built to read and preserve rotation metadata rather than blindly copying the video stream, and be aware that some phone or OS-level "save a copy" or re-share actions re-encode video and can silently drop the flag even before you run a separate converter. When picking a converter, look for one that explicitly mentions handling orientation correctly — [PixelTools' MOV to MP4 converter](/convert-video/mov-to-mp4) is one option worth trying — and always play back the result before deleting your original, so a dropped flag is a quick re-convert rather than a lost recording. That tool tries a plain stream copy first specifically because remuxing without re-encoding leaves the container's rotation matrix completely untouched; it's only the re-encode fallback, used when the source codec isn't compatible, where metadata like this is at any real risk.