Image Rotate / Flip

Rotating an image is one of the simplest operations in image processing, and it is also the operation people most often want to undo a phone's autorotation mishap, fix a scanned document that came out sideways, or prepare an asset for a layout that needs a specific orientation. The CSS `transform: rotate(90deg)` you can write in a stylesheet only affects how the image displays in *your* page; it doesn't change the file. This tool changes the file.

The implementation is a textbook canvas operation: decode the source image, create a new canvas with the rotated dimensions (width and height swap for 90° / 270°), translate to the center, apply the rotation matrix and optional flip scale, draw the source at its centered origin, then re-encode as JPG or PNG matching the input format. All four operations — rotate left, rotate right, flip horizontal, flip vertical — compose cleanly with each other, and the live preview re-runs the pipeline on every state change so what you see is exactly what gets downloaded.

A few subtleties worth knowing.

**Re-encoding is lossy for JPG.** Each save through canvas produces a new JPEG quantization pass at 95% quality. One pass is imperceptible. Ten passes — rotating, saving, opening, rotating again, saving again — eventually compounds to visible blocking artifacts in flat areas (sky, walls). For workflows where you'll rotate multiple times, do all the rotations in one session here, save once, and don't reopen-and-re-rotate the result.

**EXIF orientation is ignored.** Many phone JPGs ship with an `Orientation` EXIF tag like `Orientation: 6 (Rotated 90° CW)`. The pixel data on disk is in one orientation; the tag tells viewers to display it in a different orientation. Some viewers honor the tag (most modern image viewers, most photo apps), others don't (older browsers, some forum upload pipelines, raw `<img>` tags in older browsers). This tool reads the pixel data as-is, ignoring the orientation tag, so when you rotate, you're rotating the *actual* pixels — the output has no orientation tag and will display correctly anywhere.

**Metadata gets stripped.** This is a side effect of canvas re-encoding, not a deliberate feature, but it has the same effect as the EXIF Stripper tool: the output has no EXIF, no IPTC, no XMP, no GPS coordinates. Drop a phone photo here, rotate it 0 degrees (or one full 360°), and the output is metadata-free.

**Output size often grows.** Re-encoding picks default JPEG quantization tables that are usually less optimal than what your camera or photo editor chose. The output is often 10–30% larger than the input for the same visual quality. If file size matters, run the result through the Compress Image tool.

**Only 90° increments.** Arbitrary-angle rotation (like 5° to fix a tilted horizon) needs decisions this tool doesn't make: should the resulting bounding box be cropped to remove the empty corners, padded with white, or kept transparent? What interpolation should be used for sub-pixel sampling? These are dedicated-editor questions. For a tilted horizon, the Image Crop tool can cut out the misaligned portion.

The tool also doesn't handle multi-frame GIFs or animated WebP — only the first frame gets transformed and the result is a static JPG. For animated formats, command-line tools like `gifsicle` or `ffmpeg` are the right destination.

Everything runs in your browser. The canvas API is universal; there are no external libraries. The output is generated client-side and downloaded directly from a blob URL — no network requests during the rotation. Object URLs are properly revoked when the tool unmounts, so memory doesn't leak even if you process several images in a row.