Sideways Video? Fix Rotation Without Re-Encoding

A sideways video is usually not sideways. Phones record landscape frames no matter how you hold them, then write a rotation instruction into the file telling players to turn the picture when they display it. So a clip that looks correct in your camera roll and wrong in a desktop player, an editor, or a browser upload preview is a file whose instruction one program read and another ignored. That gives you two very different fixes: change the instruction, which is instant and costs no quality but only works where the instruction is honoured, or rotate the actual pixels, which costs one re-encode and is correct everywhere. Which one you need depends entirely on whether the clip is sideways in one player or in all of them.

Why is your video sideways in one app and not another?

A phone camera sensor is soldered in at a fixed orientation. It reads out a landscape image whether the phone is upright, on its side, or lying on a table. Turning that image at capture time would mean re-drawing every frame while the encoder is already working flat out, so the phone does the cheap thing instead: it stores the frames exactly as the sensor produced them and records, separately, which way up the result should be shown.

That separation is the whole story. The picture data and the instruction about how to present it live in different parts of the file. Any program that reads the container header before it draws anything will turn the picture for you. Any program that goes straight to the compressed frames, or that was written for a workflow where footage always arrived the right way up, will show you the raw landscape image and look broken.

This is why the same file can be fine in your photos app, fine in a modern browser, and lying on its side in an older desktop player, a thumbnail grid, or the import view of a video editor. Nothing about the file changed between those programs. Only one small field is being read or skipped.

What is a rotation flag?

"Rotation flag" is a convenient name for something that is not really a flag. MP4 inherits its box layout from Apple's QuickTime file format, and one of the pieces it kept is the track header box, tkhd, which describes a single track's characteristics. Apple's reference for the track header atom lists its fields with their byte sizes, and among them is a matrix structure occupying 36 bytes.

Thirty six bytes is nine 32-bit values, which is a 3 by 3 matrix. Apple's page on display matrices in QuickTime describes it as a transformation matrix that maps points from one coordinate space into another, covering translation, rotation and scaling in one structure. The values are 32-bit fixed point, split 16.16 for most entries and 2.30 for the {u, v, w} column, and they are written in the order a, b, u, c, d, v, x, y, w.

So a quarter turn is nothing more than a particular arrangement of nine numbers in a header. The encoded frames underneath are untouched. That single fact is why the cheap fix exists at all: rewriting nine numbers is a byte edit measured in milliseconds, while rewriting every frame is a full encode.

FFmpeg models the same idea on the command line. Its command line documentation describes -display_rotation as setting video rotation metadata, a decimal number of degrees by which the video should be rotated counter-clockwise before being displayed, and states plainly that the option overrides whatever rotation or display transform metadata the file already carries. The same page documents -autorotate, which is enabled by default and applies the stored rotation during decoding, with -noautorotate to switch that behaviour off. Turning autorotate off is the fastest way to see what a player that ignores the header sees.

Which symptom points to which cause?

Match what you are looking at against this before you touch the file. The cause decides whether a lossless fix is even on the table.

What you see	What is actually wrong	Lossless fix possible?
Upright in one player, sideways in another	The frames are landscape and the header says to turn them. One program reads that, the other does not.	Only in theory. Changing the value does not make the ignoring program start reading it. Bake the pixels.
Sideways in every player, including the camera roll	The frames are landscape and there is no rotation value, or it says zero.	No. There is nothing in the header to correct, so the picture has to be re-drawn.
Was fine, upside down after an edit or export	The editor read the header, turned the pixels, and then wrote a rotation value on top of the already-turned picture. The two corrections stack.	No, not from the exported file. Re-export without the second correction, or rotate the export 180 degrees.
Went sideways after a container change or a stream-copy trim	The picture data was copied unchanged, but the rotation value was not carried across.	Yes. This is the one case where the metadata fix is exactly right.
Text reads backwards, faces on the wrong side	A mirror, not a rotation. Usually a front camera that saved its mirrored preview.	No. Mirroring is a pixel operation, and no amount of rotating undoes it.

The middle rows are the ones that trip people up. An upside-down export is rarely a bug in the editor. It is two programs each politely applying the same correction once.

When can rotation be fixed without re-encoding?

Only when the thing that is wrong is the stored value, and only when everything downstream of you will read that value.

The mechanics are appealing when they apply. Copy the streams into a new container, write a different rotation, and the compressed picture data is bit-for-bit identical to what you started with. There is no generational loss because nothing was decoded. The operation runs at disk speed rather than encode speed. FFmpeg's documentation spells out the condition: when the video is copied rather than transcoded, the rotation you set is written into the output file as metadata, provided the muxer supports it. MP4 and MOV have somewhere to put it, because the matrix is part of the track header they both write.

The catch is that a metadata fix inherits the original problem. The program that ignored the first value will ignore the new one just as cheerfully. If your clip looks right in your photos app and wrong in the editor you are about to import it into, correcting the number changes nothing about the import.

That leaves two situations where the lossless route is genuinely the right call. The first is a value that was lost or written wrong, which is the fourth row in the table above: a container change or a stream copy dropped it, or an export wrote zero when it meant ninety. Restoring the correct number puts the file back the way it should have been. The second is when you control the entire chain and you know every program in it reads the header.

Everywhere else, turn the pixels. That means decoding each frame, rotating it, and encoding it again. FFmpeg does the turn with the transpose filter, and the filter documentation lists its directions: clock for ninety degrees clockwise, cclock for ninety counter-clockwise, plus cclock_flip and clock_flip, which combine a quarter turn with a vertical flip. A 180 degree turn is two clockwise transposes in a row. The docs also note that the old numeric values are deprecated in favour of those symbolic names, and that a passthrough option can skip the transposition when the input is already portrait or already landscape.

VidClip's rotate tool runs exactly that chain, compiled to WebAssembly, on your own machine. Clockwise is a single transpose, counter-clockwise is the other direction, 180 is two in a row, and the two mirror options are the flip filters below. It re-encodes at a high quality setting, so the result is a real generational encode rather than a header edit, which is the point: the corrected file is correct in every player, not just the ones that read headers. Two honest caveats. The free tier caps input at 200 MB and puts a small mark in the corner of video exports, because re-encoding is what makes a watermark possible at all. Pro removes both.

How do you flip or mirror rather than rotate?

Rotation and mirroring get used interchangeably in conversation and they are not the same transform.

Rotating 180 degrees is what you would get by spinning the camera around the axis pointing out of the lens. The picture is upside down, but the geometry is intact: turn your head and the text still reads left to right. Mirroring reflects the image across an axis. Text comes out backwards, and no amount of rotating brings it back, because a reflection is not a rotation in two dimensions.

Front cameras cause most mirror confusion. The preview on screen is mirrored so that moving your left hand moves the left side of the image, which is what a mirror does and what your brain expects. Some phones save that mirrored version and some save the true one, so a recording can look reversed compared to the preview you were watching while filming, without anything being wrong.

FFmpeg keeps the two operations in separate filters. The filter documentation gives hflip a one line description, flip the input video horizontally, and vflip the vertical equivalent, each with a single example command. There are metadata versions too: the command line docs list -display_hflip and -display_vflip, which set whether the image should be flipped on display, and note that they are applied after any rotation set with -display_rotation. Same trade as before. Instant and lossless, and honoured only by software that bothers to read the field.

How do you make the fix stick everywhere?

Bake it, then check it in the least forgiving program you own.

Work in this order and you will only pay for one encode:

1. Identify the symptom against the table above. If the clip is only wrong in some players, you have a header disagreement and baking is the durable answer. If it is wrong everywhere, baking is the only answer.
2. Rotate first, edit second. Rotating is an encode no matter who does it. Trimming does not have to be, because a stream copy can cut without decoding anything, as covered in how lossless trimming and keyframes work. Rotate the source once, then trim the corrected file losslessly. Do it the other way around and you either encode twice or fight the flag again.
3. Check the output somewhere that ignores headers. If the file looks right in a program that draws raw frames, it will look right in the ones that read headers too. Correct in the strict player means correct everywhere.
4. Re-check after any container change. Converting between MOV and MP4 is where rotation values most often go missing, which is worth knowing before you convert MOV to MP4 on footage you have already corrected.
5. Remember that rotating changes the shape. A 1920 by 1080 clip becomes 1080 by 1920. If you needed a specific frame shape rather than a specific orientation, that is a crop, and the crop tool is what sets aspect ratio.

If the clip is sideways right now, rotate it here and download the corrected file: the whole run happens in the page, the file never leaves your machine, and there is no queue to wait in. The full tool list covers the trim, crop and convert steps you will probably want next.

Frequently asked questions

Why does my iPhone video play sideways on Windows?

Because the iPhone stored landscape frames plus a rotation value in the track header, and whatever is opening the file on Windows is drawing the frames without reading that value. Modern Windows players generally handle it; older ones, thumbnail generators, and some editor import paths do not. The file is not damaged and it will still look correct back on the phone. If you need it correct on both, rotate the pixels rather than adjusting the value, because the program that ignored the first value will ignore a corrected one.

Does rotating a video lose quality?

Turning the pixels does, slightly, because the frames have to be decoded and encoded again, and that is one generation of lossy compression. At a sensible quality setting the difference is not visible in normal viewing, but it is real. Changing only the rotation value in the header loses nothing at all, since the compressed data is copied untouched. The trade is coverage: the lossless version is only honoured by software that reads the header, and the re-encoded version is correct everywhere.

How do I mirror a video?

Use a flip, not a rotation. FFmpeg's hflip filter reflects the picture horizontally, which is the one that undoes or applies the selfie-camera reversal, and vflip reflects it vertically. On this site both are options in the rotate tool alongside the quarter turns. Check the result against text in the frame: if writing reads correctly, you have it the right way round. Rotating will never fix a mirrored clip, and mirroring will never fix a sideways one.

Why did my video rotate after uploading?

Almost always because the receiving service transcoded it and handled the rotation value differently to your player. Some pipelines apply the stored rotation and then carry the original value forward as well, which corrects the picture twice. Others strip the value while copying the frames, which leaves the raw landscape image with nothing telling anyone to turn it. Either way you cannot fix it on the service's side. Rotate the pixels locally before uploading, so the file carries no instruction that anything downstream can misread.

Sources

• Apple, Track header atom ('tkhd'), QuickTime File Format documentation
• Apple, Matrices, QuickTime File Format documentation
• FFmpeg project, ffmpeg command line documentation (-display_rotation, -display_hflip, -display_vflip, -autorotate)
• FFmpeg project, ffmpeg filters documentation (transpose, hflip, vflip)