You shot a clip in portrait, it looks perfect in Photos, you convert it to MP4 — and now it plays sideways on YouTube, in Premiere, or in your friend's Android gallery. Nothing is corrupted and you didn't do anything wrong. Your phone never actually rotated the pixels; it wrote a small rotation flag next to them and trusted every future app to read it. Some apps don't.
This guide explains what that flag is, which tools drop it, and gives you two concrete fixes: a lossless metadata rewrite that takes a second, and a re-encode that bakes the rotation into the picture so nothing can ever misread it again.
The rotation flag vs. actually rotated pixels
An iPhone camera sensor is physically mounted in one orientation. When you hold the phone upright, the sensor still captures a landscape frame — for example 1920×1080 — and the phone records exactly those pixels. Instead of rotating the image (which would cost CPU, battery and quality), iOS writes a display matrix into the MOV container that says "rotate this 90° clockwise when you show it".
So a portrait iPhone video usually contains:
- Pixel data: 1920×1080, landscape, lying on its side
- Side data: a display matrix with
rotation: -90(or 90, or 180) - No other hint that the video is meant to be portrait
Photos, QuickTime, iMessage and modern browsers all read the matrix and show the clip upright. A tool that ignores the matrix — or copies the video stream into a new container without carrying the matrix across — shows you the raw landscape pixels. That is your sideways video. Same bytes of picture, different instruction attached.
Upside-down clips are the same story with rotation: 180, which is what you get when the phone decides "up" is the other way round, or when a GoPro or action cam is mounted inverted.
Where the flag gets lost in a conversion
Three failure modes cover almost every case of a video rotated the wrong way after conversion:
- The flag is dropped. A remux copies the H.264 stream into an MP4 but writes no display matrix. Every player now sees a landscape video and is technically correct.
- The flag survives but the player ignores it. Older VLC builds, some smart TVs, Windows Media Player, many NLE timelines and a lot of upload pipelines read only width and height.
- The flag is applied twice. A converter rotates the pixels and keeps the original flag, so a compliant player rotates again and you end up 180° off.
Screen recordings are a special case worth knowing about. An iOS screen recording of a portrait app is usually stored portrait with no rotation flag at all — but if you rotated the phone mid-recording, or recorded a landscape game, you can end up with a landscape file plus a flag that only some players honour. Android screen recordings are typically written with real portrait pixels, which is why they survive conversion better.
Step 1: read the flag before you fix anything
Guessing the direction wastes a re-encode. Ask the file:
ffprobe -v error -select_streams v:0 \
-show_entries stream=width,height:stream_side_data=rotation \
-of default=nw=1 IMG_4312.MOVTypical output for a portrait iPhone clip:
width=1920
height=1080
rotation=-90Landscape pixels plus rotation=-90 means the file is correct and your target app is the problem. Landscape pixels and no rotation line at all means the metadata was already stripped — you'll need to add it back or bake the rotation in.
Fix A: rewrite the flag (lossless, instant)
If the pixels are fine and only the instruction is wrong or missing, don't re-encode. ffmpeg 6.0 and newer accept -display_rotation as an input option, applied before -i:
ffmpeg -display_rotation:v:0 -90 -i IMG_4312.MOV \
-c copy -map 0 IMG_4312_fixed.mp4Positive values rotate counter-clockwise, negative values clockwise. A 118 MB, 42-second clip finishes in under a second and comes out byte-for-byte identical in quality, because -c copy never touches the video stream. Use 180 for an upside-down clip and 0 to strip a bogus flag that a previous converter left behind.
The catch: you've fixed the metadata, not the pixels. Any downstream tool that ignores display matrices will still show it sideways. That's when you go to Fix B.
Fix B: bake the rotation into the pixels (transpose)
This is the bulletproof option for YouTube uploads, editing timelines, TVs and anything you can't control. Because modern ffmpeg auto-rotates on decode, add -noautorotate so your filter isn't stacked on top of an automatic rotation:
ffmpeg -noautorotate -i IMG_4312.MOV \
-vf "transpose=1" \
-c:v libx264 -crf 20 -preset medium \
-c:a copy -metadata:s:v:0 rotate=0 \
IMG_4312_upright.mp4Transpose values, memorised once and never looked up again:
transpose=1— 90° clockwise (the usual iPhone portrait fix)transpose=2— 90° counter-clockwisetranspose=2,transpose=2— 180°, for upside-down footagehfliporvflip— mirrored selfie footage, no rotation involved
The output is now genuinely 1080×1920 with rotate=0, so there is nothing left to misinterpret. Cost: a real re-encode. At -crf 20 the quality difference is invisible on a phone clip, and the file often shrinks — that 118 MB MOV typically lands around 60–80 MB as MP4. Keep the original if you plan to edit further.
The no-command-line route
If you just need the clip to behave on WhatsApp, Drive or a client's Windows laptop, skip ffmpeg. Run it through the MOV to MP4 converter: it reads the display matrix on the way in and writes an MP4 whose orientation is consistent, so the file that comes back doesn't depend on whether the next player bothers to check the metadata. Drop in IMG_4312.MOV, download IMG_4312.mp4, re-upload.
The same applies to clips from other cameras and screen recorders — the video converter hub covers the other input formats you're likely to be handed, from MKV and AVI to WebM.
Quick sanity check before you re-upload anywhere: open the result in two different players — a browser tab and your OS's default player. If both show it upright, the orientation is safe to publish.
Which fix should you pick?
- Only one app shows it sideways, everything else is fine? The file is correct. Rewrite the flag with
-display_rotationor re-export through a converter — don't re-encode for one stubborn player if you can avoid it. - Uploading to YouTube, TikTok, a client, or dropping into an editor? Bake it in with
transposeso orientation can never be renegotiated. - Archiving the original? Keep the untouched MOV plus a fixed MP4 for sharing. The lossless flag rewrite is the safest thing to apply to a master file.
- Not comfortable in a terminal? Convert MOV to MP4 online and check the output in two players.
Either way, you never need to re-record. The picture was always right — only the note attached to it got lost.
Frequently asked questions
Does fixing rotation reduce video quality?
Rewriting the rotation flag with -c copy is completely lossless — the video stream is untouched. A transpose re-encode does re-compress, but at -crf 20 or better the loss is imperceptible for phone footage.
Why does my video look fine on my iPhone but sideways on Windows?
iOS reads the display matrix; several Windows players and older VLC builds don't. The file is identical — only the interpretation differs. Bake the rotation in if the clip has to work on unknown machines.
My video came out upside down instead of sideways — why?
Something applied the rotation twice: the converter rotated the pixels and kept the original 90° flag, or you ran transpose without -noautorotate. Check with ffprobe, then either clear the flag (-display_rotation 0) or rotate the remaining 180°.
Can I fix rotation without converting the whole file?
Yes — that's exactly what the -display_rotation plus -c copy command does. It rewrites a few bytes of container metadata and finishes almost instantly, even on multi-gigabyte 4K files.
Why don't iPhones just record portrait video properly?
The sensor has a fixed orientation, and rotating every frame in real time would burn battery and encoder throughput for no quality gain. The display matrix is a standard, efficient solution — it just assumes every downstream tool honours it.