It means the photo is read straight off your own disk and rendered inside the tab, so there is no copy of it on a server to store, lose, or list in a gallery. In practice that buys you four things: no upload size ceiling, no waiting for a transfer, no account, and a tool that keeps working with the network switched off. Loading an image here produced zero network requests — the only two entries in the request log were a data: URL and a blob: URL, and both of those live in memory rather than on a host.
What happens to the file, step by step
There is exactly one way in: you give the tool a file. The file picker, a drag-and-drop onto the canvas, and a paste are the three doors, and behind all three the browser hands the page a handle to a file sitting on your own disk. There is no URL box, and that detail matters more than it looks — it is the difference between a page that reads your file and a page that fetches a copy of it.
From there the decode happens inside the tab. The tool tries three routes in order and keeps the first one that survives a real paint test: an <img> element pointed at an in-memory object URL, then createImageBitmap(), then a FileReader data URL. Each candidate is probed by drawing it into a one-pixel canvas and reading that pixel back, because some engines hand back a bitmap that later draw calls refuse. All three routes are local. None of them is a request.
The decoded image is drawn onto a canvas, the torn edge is synthesised over it, and the frame you see in the preview is the frame that gets exported. The still export rasterises that canvas directly; the clip export records it. Your pixels travel from disk to memory to canvas to a download, and never through a socket.
That is a claim worth testing rather than believing, so it was tested here. A 900×600 test image was built in the page and handed to the tool through its own render entry point, the cutout was switched on, and one frame was rendered. The tool reported back that it had loaded a 900×600 image and that the cutout had removed 418,590 of 540,000 pixels — 77.52% of the frame, with real content on the canvas. The network log for that whole sequence held exactly two entries: a data: URL and a blob: URL. Neither is a host. Nothing was requested.
The order of the three decode routes is deliberate: the <img> route is the most universally drawable, createImageBitmap is the fastest when it works, and the FileReader data URL is the one that almost never fails. A page that silently gave up after the first route would reject images that this one renders fine.
What no upload actually buys you
Stripped of the slogan, running without an upload changes five things, and all five are practical:
- No size ceiling. The browser reads the file locally, so there is no multipart upload limit and no server-side cap. A 40 MB camera file is a decode cost, not a transfer.
- No waiting. Rendering starts the moment the file is decoded. There is no progress bar for an upload, because there is no upload to wait on.
- Nothing to leak. There is no server-side copy of your image, no storage bucket and no gallery, so there is no copy to be breached, sold or shown to someone else.
- No account. There is nothing to store your work under, which is why there is no sign-up, no email and no project library.
- It survives a dead connection. Once the page is open, rendering and exporting need no network at all. Load the page while you have a connection and you can keep working with the network off.
What no upload does not mean
It does not mean the page makes no requests. Opening it also fetches an analytics script and sends one page-view signal back — that is how the site counts visitors, and it is set out on the privacy page. Your image is not part of either one. The honest framing is narrow and worth keeping narrow: no upload protects your image, it does not make the site silent. A page that blurred those two things would be selling you a feeling instead of a fact.
It does not mean unlimited resolution. Without an upload, the bottleneck moves to your machine. The image is fitted to a working canvas of up to 1600 pixels on the long side, so a 4000-pixel photo is scaled down to fit, and the status line reads both sizes back — something like Loaded 3840×2400 → working at 1600×1000. A very small image goes the other way: it is scaled up toward a 560-pixel short side, with the upscale itself capped at 64×, so the tear has room to exist instead of collapsing into a blank square.
It does not mean the tool can reach into a URL. You bring a file. The cutout works by reading pixels back off the canvas, and an image pulled from another origin taints the canvas so that read fails. A local file is therefore not merely the private route — it is the only route the cutout can actually run on.
How this compares to a tool that does upload
A tool that uploads is not automatically worse; it is a different trade. Server-side work buys things a browser cannot do alone — a real segmentation model, MP4 encoding, batch runs, a project library that follows you between machines. What it costs is that your file is now somewhere you cannot see, and you are relying on a policy page to find out what happens to it next.
So run the test instead of reading the promise. Open the tool, open your browser's network panel, and drop in an image. If the request list does not change, the file stayed home. If a request appears with your image in it, the file did not. That takes about ten seconds, it works on any tool, and it does not depend on anyone's marketing copy being true.
The same test is the one this page expects you to run on it.
The short version
No upload is not a slogan here, it is the architecture. The file is read from your disk, decoded in the tab, drawn to a canvas, and the export comes off that same canvas — and loading an image produces no request at all. Everything else follows from that: no size ceiling, no account, no server-side copy, and a tool that still works with the cable pulled. If you ever want to know whether a tool means it, the network panel answers in ten seconds.
Questions people actually ask
Is my photo uploaded when I use this tool?
No. The file is read from your disk into the tab and processed there. Nothing is posted to a server, so there is no copy of it anywhere but your own machine.
Can I check that for myself?
Yes, and you should. Open the page, open your browser's network panel, and load an image. On this machine the log stayed empty apart from a data: URL and a blob: URL. A tool that uploads will show the image leaving in the request list.
Does no upload mean the page makes no network requests at all?
No, and it is worth being precise about that. The page also loads an analytics script and sends one page-view signal, which is disclosed on the privacy page. That is about counting visits, not about your image — nothing about your photo travels with it.
Why can't I paste an image URL instead of a file?
Because the cutout reads pixels back off the canvas, and an image pulled from another origin taints the canvas so those pixels cannot be read. Handing over a local file is the route that keeps the cutout working.
Is there a file size limit?
Not one that comes from an upload. The browser reads the file locally, so there is no transfer cap. The real limits come from the machine: the image is fitted to a working canvas of up to 1600 pixels on the long side, and a very large photo simply takes longer to decode.
Does it work offline?
Once the page has loaded, yes. Rendering and exporting need no connection, so you can open the page and then work with the network switched off.
Do I need an account?
No. There is no sign-up and no email, because there is nowhere to store your work — the tool has no project library and keeps no cloud copy.