Rounding image corners online is safe to do when the tool processes your file locally inside the current browser tab and never transmits it to a remote server, and Round Image Corners is built around exactly that contract. It decodes a local JPG, PNG, or WebP, clips it to a rounded rectangle on a same-size canvas, and exports a PNG with transparent corner pixels, all without an upload step in between. The word "online" in a tool's name is not the same as "on someone else's server," and that distinction is what most privacy worries miss: a browser-side tool can be reached through a public URL while still handling your pixels with the same File and Blob APIs a desktop app would use. What makes the practical difference is whether the bytes leave the browser through a fetch, XHR, or WebSocket call, or stay in memory until you click download yourself and the file is handed back through a normal save dialog.
What "safe to use online" actually means for an image tool
An image tool earns the label "safe to use online" when the same bytes you select never reach a machine you do not control. The easiest way to verify that is to open the browser's network panel before you click anything: if the page only loads its own HTML, CSS, JavaScript, and font files at first render, and never sends your selected image back out, you are looking at a browser-side tool. If instead you see a POST request carrying your image to a third-party domain the moment you choose a file, the photo has been uploaded, even if the page reassures you otherwise in friendly copy.
Several design choices are reliable signals of a safe, browser-side tool:
- The file is opened through an <input type="file"> or a drag-and-drop File object, never through a server endpoint.
- Operations use the browser's built-in Canvas, FileReader, and Blob APIs rather than remote image-processing libraries.
- The download is offered through URL.createObjectURL on a Blob, not as a link to a CDN or a tracked redirect.
- Object URLs are revoked when replaced or when the component closes, so temporary references do not linger.
- Every limit and every failure shows up as a visible message on the page rather than a silent partial output.
The same privacy questions apply to other browser-side converters. When a JPG is turned into a PNG, the file has to be re-encoded either way, and the only thing that varies between a trustworthy tool and an unsafe one is where the bytes go during that re-encode. The underlying question is the same: does the converter stay inside the tab, or does it bounce the bytes through someone else's API?
How Round Image Corners keeps your photo in your browser
Round Image Corners follows the browser-side pattern end to end. When you pick a local file, the tool stores it as a File object, creates a temporary Object URL for the preview, decodes the pixels into an offscreen HTMLCanvasElement, and never calls fetch or XMLHttpRequest with that data. The clipping operation uses the standard canvas path API: a rounded rectangle is created with CanvasRenderingContext2D.roundRect, then applied through CanvasRenderingContext2D.clip, which masks drawing to the rounded shape. The original source is drawn once at its natural dimensions, the pixels outside the rounded path are left fully transparent, and the canvas is encoded to PNG.
Because every step happens against browser primitives, the only place your image exists during processing is the page's memory. The download is produced through canvas.toBlob, wrapped in a fresh Blob URL, and triggered as a same-origin click. Temporary Object URLs are revoked the moment they are replaced or when the component closes, so a stale download link cannot reappear for a different image. Stale asynchronous exports are also guarded against: changing the source file or the radius invalidates the previous result, so a slow encode from an earlier choice cannot overwrite the newer preview you are looking at.
The visible result line is another privacy plus. It reports the exact output dimensions, the whole-pixel radius that was actually applied, the output format, and the approximate byte size, which means you can verify on the page that the file has not been silently resized, cropped, or recompressed in a way that would surprise you.
Round corners on a local photo, step by step
- Click the file picker and select a local JPG, PNG, or WebP. Make sure the file is no larger than 25 MiB on disk and that its decoded pixel dimensions stay within the shared browser safety budget of 20,000 pixels per side and 40 megapixels total. Files outside these limits, empty files, unsupported types, and decode failures all surface as a visible error rather than a silent fallback.
- Move the radius slider from 1% to 50%. The percentage is deliberately tied to the shorter side of the image: for a 400 by 200 pixel landscape, a 25% setting creates a 50 pixel corner radius, and for a 200 by 400 pixel portrait, the same 25% setting uses the width and produces the same 50 pixel radius. The result line shows the exact whole-pixel value that will be used.
- Select Round corners. Inspect the same-size PNG preview, then download the file. The output keeps the source's original width and height; only the corner pixels become transparent. The downloaded file's name ends in -rounded-corners.png so the format change is obvious in your downloads folder.
To try a different radius, simply move the slider and select Round corners again. The earlier result is invalidated as soon as the radius changes, and a new same-size PNG is produced without re-uploading anything, because nothing was uploaded in the first place.
Format, file size, and pixel limits at a glance
| Limit | Value | What happens if you exceed it |
|---|---|---|
| Supported input formats | JPG, PNG, WebP | Other formats are rejected with a visible error. |
| Maximum file size on disk | 25 MiB | Larger files are rejected before decoding. |
| Maximum pixels per side | 20,000 | Decoded images beyond this are rejected. |
| Maximum total megapixels | 40 MP | Decoded images beyond this are rejected. |
| Radius range | 1% to 50% of the shorter side | Outside-range or non-numeric values are rejected. |
| Output format | PNG only | PNG is required because JPEG cannot store transparency. |
| Output dimensions | Same as source | The canvas is never resized before encoding. |
These limits are checked before the round operation runs, not after. Empty files, unsupported MIME types, unavailable canvas support, invalid radius values, and failed PNG encoding all surface as visible errors instead of producing a partial or silent download.
Output quality, transparency, and metadata trade-offs
The output PNG keeps every pixel inside the rounded rectangle intact and leaves the corner pixels fully transparent. That means existing transparency inside a PNG or WebP source, for example an image you have already masked in a layered editor, is preserved within the clipped shape, subject to normal browser decoding and PNG encoding. The corner radius is rounded to a whole output pixel, so the rendered curve is crisp at the source's natural resolution rather than fuzzy from sub-pixel approximation.
There are a few honest trade-offs to be aware of. First, the output is always a PNG, even when the source is a JPG. PNG is required because JPEG cannot store the transparent corner pixels; that means a JPG source is decoded and re-encoded, and its output byte size can be larger than the original. Second, EXIF metadata is not carried over. Browser canvas export creates new PNG pixels from the decoded bitmap, and the canvas pipeline does not copy source metadata into the resulting Blob. Third, the tool clips the source as-is: it does not shrink the displayed preview and then export that smaller version. The preview may be scaled for layout, but the downloaded PNG always reflects the source's full dimensions. If you need to preserve EXIF or work with a reversible source file, plan on using a layered desktop editor afterwards.
When a desktop editor is the better choice
Browser-side rounding covers the common case: a single image, one equal radius for all four corners, transparent corners, no resizing. Several jobs are outside its scope, and you should reach for a desktop or layered tool for those:
- Per-corner radii: this tool applies one radius to all four corners. Use a vector or layered editor if you need asymmetric corners.
- Reversible editing: the PNG export cannot be undone inside the tool. If you want to keep the original untouched, edit on a duplicated layer.
- EXIF and metadata preservation: the canvas pipeline does not pass metadata through, so a camera's colour profile, GPS, or copyright fields are stripped from the export.
- Batch processing: only one image is handled at a time. For dozens of files, a local script or a desktop batch action is faster.
- Print colour management, shadow, gradient, decorative frames, and other design passes: those belong in a full image editor.
For the everyday job of softening the corners of a single local photo, such as avatars, thumbnails, app cards, or social posts, the browser-side path in Round Image Corners is a privacy-respectful option. The image never leaves your tab, the output is a same-size transparent PNG, and every limit and error is visible on the page rather than hidden behind a misleading success state.