How to Edit Images in the Browser Without Uploading Them

Every in-browser image edit follows the same three steps. The file is decoded from its compressed form into raw pixels, those pixels are manipulated in a canvas, and the result is encoded back into a new file. Nearly every counter-intuitive behaviour in image editing follows from this being a round trip rather than an edit in place.

The most important consequence: the output is a genuinely new file built from pixels, not a modified copy of the input. Everything that was in the original but not in the pixel grid — metadata, embedded thumbnails, colour profiles, trailing data — is simply absent from the result. That is useful when you want metadata gone and a problem when you wanted it kept.

The usual problem is a hard ceiling: under 2 MB for a form, under 100 KB for an avatar, under 500 KB for an email attachment. There are two independent levers, and reaching for the wrong one first is what produces a blurry, blocky result.

• →Dimensions — how many pixels there are. Halving both width and height removes three quarters of the pixels and usually most of the file size, with no visible cost if the image was larger than it will ever be displayed.
• →Quality — how aggressively those pixels are compressed. Below roughly 0.7 on a JPEG, artefacts start becoming visible around edges and in flat areas like skies.

Reduce dimensions first, quality second. A 4,000-pixel-wide photo displayed in a 600-pixel column is carrying more than six times the pixels it can possibly show; shrinking it is free in visual terms, while cranking quality down on the oversized version degrades an image nobody needed at that size.

Reaching an exact target takes iteration, because the relationship between quality setting and output size depends entirely on the image content — a photo of foliage compresses far worse than a photo of a clear sky. Tools that hit a target size do it by encoding repeatedly at different settings and converging, which is why they take a moment on large files.

Resizing recomputes the pixel grid. Making an image smaller averages neighbouring pixels together and generally looks fine. Making it larger has to invent pixels that were never captured, and no amount of interpolation recovers detail that was not recorded.

This is why enlarging a small image gives you a soft, smeared result rather than a bigger sharp one. If you need a larger version, the answer is to go back to the original source — the camera file, the vector artwork, the design document — not to scale up an export.

Keep the aspect ratio unless you specifically want distortion. Changing width and height independently stretches faces and text in a way that is immediately obvious to viewers even when they cannot say what is wrong. When an image must fit a fixed shape that does not match its own, crop it rather than squashing it.

A watermark deters casual reuse. It makes an image awkward to repurpose and identifies the source when it travels. It does not prevent theft, and it is worth being clear-eyed about that before choosing how intrusive to make one.

Placement is a trade-off between how easily it is removed and how much it spoils the image. A small mark in a corner is unobtrusive and trivially cropped out. A large, low-opacity mark across the centre is much harder to remove and much more visible to legitimate viewers. Most people want something between the two: text large enough to read at thumbnail size, at 30–50% opacity, positioned over detail rather than flat background where it would be easy to paint out.

Practical details that matter more than they sound: add the watermark after resizing, or it will be scaled along with everything else and may end up illegible. Give text a subtle shadow or outline so it stays readable over both light and dark areas. And keep an unwatermarked master — you will eventually need a clean version.

Photographs from phones and cameras carry EXIF metadata alongside the image: the device make and model, exposure settings, the exact date and time, and very often GPS coordinates precise to a few metres. None of it is visible in the picture, and all of it travels with the file.

The risk is specific rather than theoretical. A photo taken at home and posted publicly carries the location of your home. A set of images shared over months carries a movement history. Sold an item online and photographed it on your kitchen table, and the listing may include your address to anyone who checks.

• →Some platforms strip metadata on upload, others preserve it, and a few strip it from the displayed image but keep it on the original download. Do not rely on this being handled for you.
• →Screenshots contain no EXIF, because there was no camera involved.
• →Sending a photo as a file attachment rather than through an image-sharing feature usually preserves everything, since nothing re-encoded it.
• →Because a canvas export rebuilds the file from pixels, saving through one removes the metadata as a side effect of how it works, not as a feature that could silently fail.

The sensible habit is to look before you share: inspect what a file actually carries, then export a clean copy if it carries more than you intended.

Hiding part of an image — a face, an address, an account number in a screenshot — looks like one task with three interchangeable styles. It is not. Two of the three common methods leave the original information present in the file.

The distinction is whether the output still depends on the input. A solid block does not: every pixel becomes the same value regardless of what was there, so there is nothing left to reconstruct. Pixelation and blur both preserve a degraded version of the original, and degraded is not destroyed.

There is a second failure mode worth knowing, independent of method. If an editor writes the edit into the original file rather than encoding a fresh one, the original data can survive past the end of the visible image — the flaw behind the Acropalypse vulnerability, where cropped screenshots could be partially restored. Exporting a genuinely new file from the edited pixels avoids it, and is another consequence of the decode-and-re-encode pipeline this guide opened with.

A favicon is a small job with an unhelpfully large amount of legacy attached. The practical minimum in 2026 is fewer files than most guides suggest.

Design for the smallest size first. A logo that reads beautifully on a website is usually illegible at 32 pixels, and detailed marks turn to mush. Most good favicons are a single letter, a simple glyph, or a heavily simplified version of the full logo — and they need real contrast against both light and dark tab bars, which is where a lot of otherwise careful branding falls down.