Rotador de imágenes gratuito

90/180/270 vs everything else, the lossless line

There are two completely different kinds of image rotation. Rotations by exactly 90°, 180° or 270° are lossless: every source pixel lands on exactly one integer destination pixel, the bitmap is permuted rather than recomputed, and there is no interpolation, no blending, no quality loss whatsoever. A 90° clockwise rotation maps pixel (x, y) in a W × H image to position (H − 1 − y, x) in the new H × W output. A 180° rotation maps (x, y) to (W − 1 − x, H − 1 − y). These are pure memory-shuffle operations.

Any other angle requires resampling: for each destination pixel, the algorithm computes where it would have come from in the source (by inverse rotation), finds the source location is generally fractional, and combines the surrounding source pixels using an interpolation kernel. The common kernels:

• Nearest neighbour: picks the single closest source pixel. Fast, preserves hard edges, but produces visible "jaggies" along rotated lines.
• Bilinear: weighted average of the four nearest source pixels. Smooth, fast, the default for most browser canvas implementations.
• Bicubic: weighted average of the 16 nearest source pixels using a smooth cubic kernel. Sharper than bilinear; the default in Photoshop's bicubic options.
• Lanczos: windowed sinc-function over a 6×6 or 8×8 neighbourhood. The highest-quality kernel in common use; significantly slower; can produce ringing artefacts on sharp edges.

Each kernel trades off detail preservation against ringing or blurring, and they all share one truth: any non-90 rotation discards some source information. Fine high-frequency detail (one-pixel lines, subpixel-positioned text edges, cleanly aliased pixel art) cannot survive a 30° or 45° rotation through any kernel without some softening. Useful intuition: rotate by 1°, then back by −1°, and you do not get the original, you get a softer copy. Rotate by 90° then by −90° and you get back the exact original bitmap.

EXIF Orientation: the silent reason your photo was sideways

The "browser shows my photo upside down" problem has a specific cause. Modern smartphones don't physically rotate the image when you take a photo holding the phone sideways, they store the original sensor orientation and add an EXIF Orientation tag (introduced by JEIDA around 1995) telling viewers how the image should be displayed. The tag has 8 possible values: 1=normal, 3=180°, 6=90° clockwise, 8=90° counter-clockwise, plus four mirrored variants.

Before about 2010, devices wrote rotated pixels and Orientation = 1; from then on, modern phones store original pixels with Orientation set instead, saves storage and battery. The catch: browsers historically did not honour EXIF Orientation outside of <img> elements. Drag a portrait phone photo onto a canvas-based tool, and the canvas would draw it sideways unless the tool explicitly read and applied the Orientation tag. The CSS image-orientation property added in 2017 fixed this for HTML; modern createImageBitmap() with imageOrientation: 'from-image' fixes it for canvas. Chrome 81 (April 2020) made image-orientation: from-image the default for <img> elements.

If you've ever rotated a photo in your browser and it appeared "already rotated", or rotated twice: you've hit this. The honest fix is for the rotation tool to read the EXIF tag, mentally apply that orientation first, then add the user's chosen rotation on top.

How the canvas does it

Canvas's rotate(angle) method rotates the coordinate system around the canvas origin (0, 0). Because the origin is the top-left corner, naively calling ctx.rotate(angle) followed by ctx.drawImage(img, 0, 0) rotates the image around its top-left corner, sending most of the rotated pixels off-canvas to the upper-left. The standard recipe corrects for this with a translate-rotate-translate sandwich:

ctx.save();
ctx.translate(canvas.width / 2, canvas.height / 2);
ctx.rotate(angle * Math.PI / 180);   // canvas takes radians
ctx.translate(-image.width / 2, -image.height / 2);
ctx.drawImage(image, 0, 0);
ctx.restore();

For a 90/180/270 rotation, the destination canvas needs to be sized to fit the swapped (90/270) or original (180) dimensions. For an arbitrary angle, the bounding rectangle of the rotated image is larger than either source dimension, for a W × H image rotated by θ, the new bounding box is |W·cos(θ)| + |H·sin(θ)| wide and |W·sin(θ)| + |H·cos(θ)| tall. A 1000 × 800 image rotated 45° therefore needs a roughly 1273 × 1273 canvas to hold every rotated pixel. The "Crop to fit" toggle decides whether to expand the canvas (preserving every pixel, with transparent or white triangular corners) or trim back to the original dimensions (clipping the rotated content).

PNG vs JPG output, the corner problem

When a non-90 rotation expands the canvas, the four triangular corners need to be filled with something. PNG can render those gaps as fully transparent pixels (alpha = 0), perfect for layering the rotated image over another background. JPG has no alpha channel and renders any unfilled pixels as the canvas's clear colour, which JPEG flattens to opaque black. A user who downloads a JPG of a rotated photo and is surprised by black wedges in the corners has hit exactly this issue.

This tool composes JPG output against a white background before encoding to avoid the black-corner problem. PNG output preserves transparency. The choice between formats: PNG for anything with transparency or where you'll edit further, JPG for photos heading to a final destination where file size matters.

There is one more nuance for JPGs. Lossless JPEG rotation is technically possible, the jpegtran utility rearranges the JPEG block boundaries (the 8×8 DCT coefficient blocks) without re-decoding the image, so a 90/180/270 rotation can leave the underlying compressed data intact and emit a JPEG that's bit-identical in quality to the original. The catch is an iMCU edge constraint: the image dimensions must be a multiple of the block size, otherwise the rotation either trims a few edge pixels or leaves a partial block. This page uses the canvas API instead of jpegtran-style block manipulation, so JPG output here is always re-encoded, at maximum quality, but with the small generation loss inherent to any JPEG re-encode.

When you'd reach for a browser rotator

• Smartphone shots that imported sideways into a desktop application that doesn't honour EXIF Orientation.
• Scanned documents that came in rotated 90° because the scanner's auto-detect was wrong.
• Print orientation: preparing an image for portrait vs landscape printing.
• Art and design composition: rotating a photograph to test different visual orientations.
• Quick fixes before social media uploads when the platform's auto-rotate gets confused.
• Sensitive content: work documents, ID photos, family photos, that you'd rather not upload to a third-party service.

More questions

Will my photo lose quality if I just rotate it 90°?

No, not in the rotation step itself, 90/180/270 rotations are lossless permutations. The quality risk is the encoder. If you upload a JPEG, this tool decodes it, rotates the pixel array, then re-encodes the result. The re-encode adds a small amount of generation loss (typically invisible at maximum quality) because JPEG is lossy. To avoid even that, download as PNG, or use a dedicated tool like jpegtran that rearranges the DCT blocks without re-decoding.

Why does rotating an SVG keep the image crisp?

Because SVG is vector, it stores shapes as mathematical paths rather than as a pixel grid. Rotating an SVG via transform="rotate(angle)" just modifies the path coordinates; there's no resampling step and no quality loss at any angle. The browser re-rasterises the rotated paths each time it redraws, always at the current zoom level. This tool operates on raster images (PNG, JPG, WebP) and so encounters the resampling cost; SVGs are best rotated by editing the transform attribute directly or by using a vector editor like Inkscape or Illustrator.

Why are the corners white instead of transparent?

You're downloading the JPG output. JPG has no alpha channel, so the triangular gaps left by a non-90 rotation get filled with white before encoding (or black, on tools that don't compose against a background, the all-too-common dark-corner surprise). Switch to PNG download and the corners will be properly transparent.

Can I rotate by 1° increments?

Yes. The slider above moves in 1° steps; the input field accepts any decimal (45.5° works fine). For very precise alignment work (straightening a tilted horizon in a photo, for example) sub-degree precision can matter. Each non-90 rotation does cost a tiny amount of quality, so for repeated fine-tuning consider doing a single rotation by the final target angle rather than several incremental adjustments.

Does anything get sent to a server?

No. The image is decoded by your browser, drawn to a canvas via the Canvas 2D API, and re-encoded for download, all in your browser process. The file never leaves your device. The tool also works offline once the page is loaded.