An image overlay tool that runs entirely in your browser is safe to use online because both source images are decoded locally, combined on a canvas inside your tab, and exported as a PNG without ever leaving your device. The safety claim, however, only holds when the tool genuinely performs all decoding and compositing on the client side, uses ObjectURLs that are revoked when files change or the page closes, and does not initiate a background upload, fetch, or analytics call tied to your image bytes. A tool that asks you to sign in, sends the file to a remote API, or stores intermediate blobs on a CDN does not meet that bar, even if its marketing page says "secure." The same is true of tools that perform the work locally but leave dangling object URLs in memory or copy your pixels into a logging endpoint. This article unpacks the technical signals that distinguish a genuinely local image overlay from one that quietly ships your photos elsewhere, then walks through the exact workflow so you can verify each step before trusting it.
What "safe" means for an online image overlay
Safety for an image overlay tool is really three questions stacked on top of each other. The first is data location: where do your image bytes physically sit while the tool is open? The second is processing model: does the tool run the decode and composite in your browser tab, or does it ship the file to a backend that returns a result? The third is side channels: even if the work happens locally, does the tool quietly call an analytics endpoint, a logging service, or a CDN that could end up with a copy of your file or a hash of its bytes?
A tool that runs entirely client-side can answer "your device" for the first question, "in your tab" for the second, and "none that touch your image" for the third. The Image Overlay tool fits that profile: no account, no fetch of image bytes to a server, no third-party analytics call that piggybacks on the canvas. That is why a browser-side image overlay is generally safe to use, and it is also why it matters to confirm those claims rather than take them at face value.
The risk profile of an online image tool is not uniform. A logo, badge, or meme graphic carries almost no sensitivity, so even an imperfect tool is usually fine for those jobs. A scanned passport, a medical record, an internal company screenshot, or a customer photograph attached to a personal note is a different story. For those inputs the only acceptable answer is that the file never leaves the tab, full stop. The rest of this article covers the technical signals that let you tell which kind of tool you are looking at.
How a browser-side overlay keeps files on your device
A browser-side image overlay does its work through a small, well-defined pipeline. The input files are read through a File reference, decoded into raw pixel buffers with createImageBitmap or a similar API, drawn onto an HTMLCanvasElement at the planned coordinates, and exported with the canvas's toBlob method. Every one of those steps can happen inside the tab; none of them require a network call. The drawImage method that places the overlay onto the base canvas is documented at MDN's CanvasRenderingContext2D drawImage reference, which is the same primitive most "private" image tools rely on.
ObjectURLs are the part most people miss. When a browser turns a File into a usable image source, it does so through URL.createObjectURL, which produces a blob URL that lives only as long as something holds a reference. If the tool forgets to call URL.revokeObjectURL when you replace the file, change the position, or close the page, that blob can stay reachable in memory longer than it should. Image Overlay revokes the prior ObjectURL whenever a new base or overlay file is selected, when an export is regenerated, and on unmount, so a swapped image cannot leak into a stale preview or download.
There is also a generation system in the background. Each file is tied to a job ID, and a separate render generation tracks a click. Decoding the overlay does not invalidate an in-progress base decode, and changing the overlay while a render is in flight invalidates only the overlay's role. Mounted-state guards reject callbacks after the component unmounts, which means a slow toBlob callback cannot overwrite state on a tool you have already navigated away from. Intermediate opacity values use the canvas's globalAlpha setting, applied once around the overlay draw, then restored, so transparent pixels in a PNG or WebP remain transparent and the base is never blended down. None of these mechanisms are visible in the UI, but together they are what turns "we do not upload" from a slogan into an enforceable contract.
Input and output limits that shape safe behavior
Safety is not only about location; it is also about what the tool refuses to do. Hard, declared limits are a safety feature because they tell you, in advance, exactly what the tool is willing to handle and what it will reject. Image Overlay publishes its limits up front and refuses inputs that exceed them rather than silently truncating, downscaling, or producing a corrupt file.
| Limit | Value | Why it exists |
|---|---|---|
| Accepted input formats | JPEG, PNG, WebP | Keeps the decoder surface narrow; GIF, SVG, AVIF are explicitly out of scope |
| Maximum compressed file size per input | 25 MiB (26,214,400 bytes) | Prevents oversized blobs from stalling the browser |
| Maximum decoded edge (width or height) | 20,000 pixels | Guards against extreme aspect ratios that blow up canvas memory |
| Maximum decoded pixel budget per image | 40,000,000 pixels | Bounds memory even when a small compressed file expands to a huge buffer |
| Output format | PNG (always) | Needed to preserve transparency from base and overlay |
| Output pixel dimensions | Equal to the base image's natural width and height | Avoids silent resizing or "fit to screen" surprises |
Boundary behavior is just as important as the limits themselves. A file exactly at 25 MiB is accepted; one byte more produces a recoverable error and no partial output. The same rule applies to the 20,000-pixel edge and the 40,000,000-pixel budget. That kind of strict, disclosed cutoff is what you want from a safe tool: when you cross the line, you find out immediately instead of getting a malformed PNG.
How to overlay two images safely in your browser
The full workflow for a safe browser-side overlay is short and predictable. Each step is reversible until you download, and you can swap either source file at any time without leaving stale pixels behind.
- Choose a base image and an overlay image. Both can be JPG, PNG, or WebP, and each file must be at most 25 MiB. The base is the canvas the result will be drawn on; the overlay is the picture you want to place on top of it.
- Pick an anchor for the overlay: center, top left, top right, bottom left, or bottom right. The anchor is a deterministic position, not a free drag.
- Set the overlay scale between 10% and 200%. The scale applies only to the overlay and uses the overlay's own natural width and height as the reference. At 100% the overlay draws at its natural size; at 50% each dimension is half; at 200% each dimension doubles.
- Choose an opacity between 0% and 100%. Zero makes the overlay fully transparent while still producing a full-base-size PNG; one hundred uses the overlay's own alpha unchanged. Intermediate values multiply the overlay's contribution by the selected global alpha.
- Create the composition. The tool clears the canvas, draws the base at alpha 1, saves state, applies the selected overlay alpha, draws the scaled overlay at the planned coordinates, then restores state, and exports a PNG at the base image's natural pixel dimensions.
- Inspect the preview, then download the PNG. Editing position, scale, or opacity revokes the prior result URL immediately, so a stale export cannot be downloaded by accident.
A worked example makes the math explicit. Suppose your base is 1600×900 and your overlay is 800×500, and you pick the center anchor at 50% scale. The overlay renders at 800 × 50/100 = 400 px wide and 500 × 50/100 = 250 px tall. Center x = (1600 − 400)/2 = 600, center y = (900 − 250)/2 = 325. The exported PNG is 1600×900, with the overlay drawn at (600, 325) at half its natural size. You can re-run the calculation for any other scale by substituting the same formula. For a deeper walk-through of the same no-upload pipeline, see the guide on overlaying one image on another without uploading files.
What is and isn't preserved in the exported PNG
Even a perfectly private overlay cannot preserve every property of the original files. PNG is the only output format because the base and the overlay may both contain alpha channels, and JPEG cannot represent transparency. That choice costs you something: PNG files are larger than the original JPEGs, and PNG does not carry the same set of metadata containers as JPEG does.
| Property | Preserved in the exported PNG? | Notes |
|---|---|---|
| Base image pixel dimensions | Yes | Output width and height always equal the base's natural dimensions |
| Transparency (alpha) | Yes | PNG supports alpha, and transparent areas are preserved |
| Original file format | No | All results are PNG, including results from JPEG inputs |
| EXIF or camera metadata | No | Re-encoding does not retain EXIF; use a dedicated EXIF editor if you need it |
| GPS coordinates | No | Stripped along with the rest of the EXIF block |
| Animation frames | No | Static image overlay does not handle animated GIF or animated WebP |
| Embedded text or ICC profiles | No | Output is a re-rendered pixel buffer, not a metadata passthrough |
| Sharp edges when scaling | Partial | Browser interpolation is used at any scale other than 100%, so edges can soften |
For most overlay jobs — a logo, a watermark graphic, a corner badge, a centered texture — the lack of metadata preservation is a feature rather than a bug. It means there is no camera serial number, no GPS coordinate, and no original filename baked into the file you share. If you actually need to keep EXIF, edit it separately with a local EXIF editor and apply it after the overlay step.
When to avoid an online overlay tool entirely
Even a safe, browser-side overlay is not the right tool for every job. Skip it, or route around any online tool, when one of the following is true for the files in question. First, if the overlay must finish at an exact pixel width, compute the scale yourself from the overlay's natural width before exporting. 100% draws at the natural size; 50% halves both dimensions; any target width can be reached by target ÷ natural × 100. Second, if the overlay at your chosen scale is larger than the base, the portion that hangs off the canvas is clipped by design, not resized. Lower the scale or edit the overlay source first if that loss is not acceptable.
Third, if you need free dragging, arbitrary x/y coordinates, rotation, blend modes, masks, or repeated tiling, the single-overlay, deterministic-anchor model is not a good fit. Those jobs belong in a real editor with undo history and visible handles. Fourth, if you care about metadata preservation, do the metadata step separately; no online overlay tool can both keep your pixels private and reattach a camera's EXIF block to the output. Fifth, if the input itself is in a format the tool does not accept — SVG, AVIF, animated GIF, RAW — convert it locally first rather than uploading it to a "universal converter" that may keep a copy. None of those caveats change the answer to the original question: yes, a browser-side image overlay is safe to use online when it actually keeps the work in your tab, revokes its blob URLs, and refuses inputs outside its declared limits. The way to keep the promise is to verify, not to trust, which is why Image Overlay publishes its limits up front and treats every byte and pixel budget as a hard, documented cutoff.