How to Edit an Image Online (and What Changes Your Pixels)

What this editor does, in one paragraph

You open a PNG, JPEG, GIF, WebP or BMP file, and the browser decodes it into a canvas in this tab. From there you can crop it, rotate it in 90-degree steps, mirror it, resize it by a uniform percentage between 10% and 400%, adjust brightness, contrast and saturation, apply a filter, draw on it with a brush, line, rectangle, arrow or text tool, and download the result as PNG, JPEG or WebP. The image is decoded, edited and encoded on your own device. There is no request for your file, no account, and nothing to install.

The format is confirmed from the file's own header bytes before the pixels are decoded, so a file that only claims to be a PNG is refused with that reason rather than failing somewhere inside a decoder. Inputs are capped at 25 MB, 16 megapixels (16 MP) and 8192 px on the long side, and every one of those is a refusal with your real numbers, not a silent crop or downsample.

Which edits are exact, and which one is not

Three of the operations move pixels and are therefore exact. Rotating by 90, 180 or 270 degrees is an exact rearrangement of the pixel grid. Mirroring is a flip of that grid. Cropping discards the pixels outside the rectangle you chose. None of the three resamples, so none of them softens the image, and none of them loses a single pixel that stays in the frame. A quarter turn swaps the sides, which is why a rotated landscape photo exports as a portrait file with the dimensions swapped rather than being squeezed.

Resizing is the fourth operation, and it is the one that does resample. The tool uses the browser's own resampler, and enlarging an image means interpolating between the pixels you already have. You get a larger file with the same information in it, interpolated. That is not an AI upscaler, and no in-browser resampler is: a generative model would be guessing at detail that was never recorded. If you enlarge a photo and it looks soft, that is the honest result of the operation rather than a bug, and the number to watch is how far you push it.

One scale is applied to both axes. A tool that let you set width and height independently could stretch a face or bend a straight wall, and this one does not offer those controls, so the aspect ratio of the frame survives every resize down to the last pixel.

A crop you set is kept, wherever you rotate afterwards

A crop is stored in the image's own pixel coordinates, not in screen coordinates, and the same is true of every annotation. That is the detail most editors get wrong in a way you only notice later: crop a photo, then rotate it, and a crop stored against the screen moves to a different part of the picture. Here the crop rectangle is carried through the rotation and mirror as a geometric transform of its four corners, so a quarter turn moves the crop with the pixels it was cutting out.

Annotations behave the same way. A stroke, an arrow or a text stamp is recorded as coordinates in the image, so it is still in the same place after a later crop, rotation, mirror or resize, and it is stored in the file's output pixels so a thin line exports thin instead of fatter than it looked on screen. There is no separate layer for it either: annotations are baked into the same single canvas, which is why there is nothing to re-order and no PSD to save.

Why an over-budget export is refused instead of shrunk

If you ask for 400% on a frame that would come out at 48 megapixels, you have asked for a specific image. Silently handing back a smaller one is not a smaller version of the same request, it is a different file from the one you asked for, and a surprising one at that. So the output is capped at 16 megapixels and 8192 px per side, with a minimum of 8 px per side, and an export that does not fit is refused with the largest scale that would fit or the crop to make first. The last render that did fit stays on screen while the refusal is on it, and the download button stays clickable so it can repeat the reason in an alert rather than sitting there disabled and unexplained.

This is the same philosophy as the input caps: the file that comes back is the file that was measured. If you need a specific large output, the honest route is to crop to the part you need and then scale, or to downscale in two steps of a known factor each.

What your file loses on the way out

Three things, all of which are invisible until someone opens the file in a different program. First, every download is encoded again from the pixels on screen. That is unavoidable in a browser editor, and it has one consequence worth stating plainly: re-exporting an untouched JPEG is a second lossy generation, and the file will drift a little further from the original each time. PNG is the only lossless choice here, and for a photo you intend to keep editing, exporting PNG between stages is the way to stop the drift accumulating.

Second, nothing that is not pixels survives. The browser decodes the image, and the metadata goes at that moment: no EXIF, no camera, no GPS, no capture timestamp, and no ICC colour profile. The output is untagged sRGB, so a photo shot in a wide-gamut space can shift slightly in colour, and that shift is a conversion rather than a mistake. The one EXIF field that changes what you see is the orientation flag, and the browser does apply it on the way in, so a sideways phone photo arrives upright rather than needing a manual rotation.

Third, animation is not carried through. A GIF or an animated WebP is decoded to its first frame, so an animated file becomes a still image of frame one and every later frame is lost. There is no frame picker, because there is no frame selection in a single canvas. If you need a specific frame, extract it first and open that instead.

Choosing a format, and the quality slider that only sometimes matters

PNG is lossless and keeps transparency, and it is the largest of the three. JPEG is lossy, has no transparency channel, and composites transparent pixels on white, so a cut-out PNG saved as JPEG gets a white background rather than a black one or a hole. WebP is lossy at the quality you set, usually smaller than JPEG at the same perceived quality, and it keeps transparency, so it is usually the better choice for the web.

The quality slider is the encoder's own 0-to-1 argument, which is why it is disabled for PNG: there is nothing to lose, so a quality number would have no meaning. On the two lossy formats, 1.00 is the encoder's best effort and 0.30 is visibly soft. One more real detail: a canvas can refuse the format you asked for and hand back another. A browser without a WebP encoder returns a PNG from a WebP request, and rather than naming that file .webp this editor names it from the bytes that actually came back, and tells you the substitution happened.

What this editor is not

There are no layers, no PSD, no selection tools, no healing or content-aware fill, no clone stamping, and no AI of any kind. There is also no HEIC, AVIF or RAW support, so a photo straight out of an iPhone in HEIC has to be converted before it can be opened here, and a camera RAW needs its own converter first. The tool covers the everyday edits and does them locally, with nothing installed; for compositing, layer work or retouching, a full editor is the right tool.

Everything here happens in your browser. The file is read locally, decoded locally, edited locally and saved locally. That matters most for the images people most want to edit privately: an unredacted contract, an internal mockup, a screenshot of something that has not been announced, or a passport photograph.