Turning a photo ninety degrees should be free. You are not changing any colour, discarding any detail, or resizing anything — you are moving pixels to different positions. And yet most rotation tools hand back a file that is measurably different from the one you gave them, in every pixel.
The reason is that they decode the JPEG to a grid of pixels, rotate that grid, and encode a brand-new JPEG. That final step is lossy. Do it four times and you are back to the original orientation with four generations of compression damage. There is a better way, and it has existed since the 1990s.
Why a JPG can be turned without being re-encoded
A JPEG does not store pixels. It stores a grid of 8×8 blocks, each described by a set of frequency coefficients. Those coefficients have a useful mathematical property: transposing and negating them in the right pattern produces exactly the coefficients you would get from rotating the image, without ever converting back to pixels.
So a 90-degree rotation can be performed entirely inside the compressed data. Nothing is decoded, nothing is re-quantised, and the output contains the same information as the input in a different arrangement. This is what the classic jpegtran utility does, and rotating four times by 90 degrees returns the exact file you started with.
Filum's Rotate Image uses that path for JPG. PNG needs no such trick — it is lossless already, so rotation moves pixels without touching their values and the result is pixel-identical.
What we measured
This is not a theoretical distinction, so it is worth stating what was actually observed rather than what is generally believed. In a direct measurement against a large free image suite, a single 90-degree turn of a JPG came back re-encoded, with millions of pixel values changed. The same platform's PNG rotation came back intact.
One turn is not a disaster — the damage from a single high-quality re-encode is small. The problem is that people rotate more than once. They rotate, look at it, rotate back, rotate the other way. Each of those is another generation, and generations do not cancel out.
The two cases where lossless is not possible, and what should happen then
The compressed-data trick has a constraint: the image dimensions must be a multiple of the block size for the transform to cover every block cleanly. When they are not, the edge blocks cannot be transformed exactly. The classic command-line tools deal with this by silently trimming a strip of edge pixels, which is a surprising thing to do to someone's photograph without telling them.
The other case is format. WebP and AVIF have no equivalent lossless rotation path, so those have to be decoded, rotated, and re-encoded.
In both cases the honest behaviour is the same: do the pixel rotation at high quality, say that is what happened, and show the measured quality of the delivered file. Filum does that rather than silently cropping edges or silently re-encoding.
The orientation tag, which is the other half of this problem
Photos from phones usually carry an EXIF orientation tag — a flag saying "display this rotated." It is why a picture can look upright in your phone gallery and sideways when you upload it somewhere: the second program ignored the tag.
A rotation tool that only changes the tag has not rotated anything; it has changed a hint that some software honours and some ignores, so the image will still appear wrong in half the places you put it. The right answer is to fold the tag into the actual rotation and then clear it, so the pixels themselves are correct and no viewer has to be trusted to interpret anything.
Filum does that, and the whole operation runs inside your browser on your own device — the photo is never transmitted anywhere to be turned ninety degrees.