Flip Video.

Turn on the horizontal flip and watch the stage: whatever was on the left is now on the right, and any text in the shot reads correctly. That is the version everyone but you was already seeing, because a front camera mirrors the preview so it feels like a mirror and then usually records the mirrored frame too. A flip cannot be done with metadata, so this one re-encodes the picture once at high quality with the audio copied straight through, and the file lands with the flip already in the pixels so every player shows it the same way.

Because the picture inside the file is sideways and a note in the container says so. Phone cameras record the sensor in its fixed orientation and write a rotation value into the video track's metadata rather than turning the frames, which is far cheaper and completely standard. Anything that reads that value shows the clip upright, and that is your phone, your browser, iOS, Android, and every modern player. Anything that does not read it shows you the sensor, which is your clip on its side. Old builds of Windows Media Player, some projectors and smart TVs, and plenty of server-side tools fall in the second group. The clip is not corrupt and nothing went wrong when you filmed it.

Fixing the flag rewrites the note. The picture is copied across byte for byte, nothing is decoded, the output is losslessly identical inside, and the whole job takes about a second regardless of how long the video is. The catch is that a player which ignored the old note will ignore the new one, so it fixes the file for everything modern and nothing else. Baking it in turns the actual pixels: every frame is decoded, rotated, and encoded again, and the note is set to zero so there is nothing left to honour or ignore. That costs one encode of quality and real time, and it is the only fix that works everywhere. Start with the flag. Bake it when you know the thing on the other end is the problem.

Only if you bake it. Rewriting the orientation flag touches no picture data at all, so there is nothing to lose: the encoded frames in the output are the encoded frames from the input. Baking is a re-encode, and every re-encode costs something. This one aims high, at about 0.12 bits per pixel at the displayed size, and it will never spend more bits than your source itself carried, so a single careful pass is invisible in practice and the file cannot accidentally get bigger. A flip always bakes, because there is no metadata form of a mirror that players respect.

Yes, and there are two ways depending on what is wrong. If the flag is simply incorrect, add the turn that makes the display right: the tool composes what you ask for on top of what is already there, so a file flagged 90 that needs another quarter turn ends up flagged 180, and the plan line shows both numbers. If the flag is correct but something downstream keeps ignoring it, choose bake with no rotation at all: that decodes the picture the way a flag-honouring player shows it, writes those pixels, and sets the flag to zero. It is the specific fix for a file that looks right everywhere except the one place it has to work.

MP4, MOV, MKV, and WebM. MP4 and MOV are the containers whose rotation metadata players actually honour, so those are the two where the instant lossless fix is available, and a MOV lands as an MP4 because that is the file anything downstream would rather have. WebM and MKV have no orientation flag worth writing, so a turn there always bakes, and the tool says so on the chip rather than quietly doing something else. AVI and the older oddities have to go through the converter first.