Safe test image habits for a new cutout tool

By Support writer

Test a new image workflow with a disposable, non-sensitive picture before opening a personal, client, or confidential photo. The best test image has a clear subject, an ordinary background, no readable private text, and no identifying details you would regret exposing.

One low-risk trial can teach you how permissions, first-run setup, local history, refinement, export, and cleanup behave. It cannot prove that software is safe in every technical sense, but it prevents avoidable surprises with valuable material.

Build a deliberately boring test image

You do not need a perfect studio photograph. Take a new photo of an everyday object you own: a mug, plain shoe, desk plant, or cardboard shape. Place it against a contrasting wall or sheet and keep documents, screens, faces, addresses, keys, badges, and reflections out of frame.

A useful test set has two files:

1. Easy image: one opaque object, even lighting, strong subject/background contrast.
2. Edge image: a harmless object with a thin handle, fuzzy leaf, small opening, or soft shadow.

The easy file verifies the basic path. The edge file shows what the model and refinement controls do when boundaries are less obvious. Neither image needs to reveal anything about a person.

Inspect the frame, not just the main subject

Private details often sit at the edge of a photo. Before opening the file, zoom in and check:

• labels with names or order numbers;
• mail, receipts, calendars, or screens;
• window reflections and mirrors;
• location clues outside a window;
• faces or identifying clothing in the background;
• vehicle plates, access cards, keys, or QR codes;
• embedded captions or watermarks you do not have permission to reuse.

Crop unnecessary areas before the test. Background removal is not a substitute for redaction: a tool must read the visible pixels before it can decide which ones belong to the subject.

Use a local source you control

Save the test image into a temporary local folder and open that file. This creates a clean baseline without involving a page-image delivery rule or a synchronized photo library.

If the folder automatically synchronizes to an online account, choose a different local folder or pause synchronization according to your device policy. The extension can process locally while the operating system independently uploads the same source or exported file.

After the local-file test works, you can separately test the right-click page-image path with a public image you are allowed to use. Keeping the two tests separate makes failures easier to interpret.

Expect setup before judging processing

The first launch may download an on-device model. Stay online until that setup finishes. A later product or model update may require another download.

Do not confuse the model request with an upload of the test photo. The purpose of the downloaded model is to let the browser perform the cutout locally. Also do not advertise the workflow as permanently offline: initial setup and updates can require a connection.

Once setup is complete, run the easy image first. Note whether failure happens during file decoding, model processing, refinement, or export. Those are different stages with different fixes.

Verify the visible data lifecycle

Process the easy image, make one obvious brush edit, and download a PNG. Then close and reopen the editor.

Check the following:

• Does a recent job appear in local history?
• Can you distinguish the original from the result?
• Does reopening preserve enough state for the advertised convenience?
• Can you find the browser control used to clear extension data?
• Does clearing local data remove the visible history?
• Does the downloaded PNG remain after history is cleared?

The last answer should be yes: downloaded files are outside the extension’s local cache. Delete the PNG separately when the test is over.

Check output without publishing it

Open the PNG in a local viewer that displays transparency clearly. A checkerboard inside the editor is only a preview; verify the exported file itself.

Look at:

• whether the expected background is transparent;
• whether the subject dimensions are useful;
• whether thin parts remain;
• whether a pale or dark halo appears;
• whether Copy and Download produce the behavior you expect;
• whether the result opens in the application where you plan to use it.

Do not upload the test result to a public post merely to inspect it. A local viewer or offline document is enough for this stage.

Learn cleanup before sensitive work

Run cleanup as part of the test, not as an emergency afterward:

1. Clear recent jobs or the extension’s browser data.
2. Delete the temporary source and exported PNG.
3. Clear clipboard history if you used Copy.
4. Empty the relevant trash area if policy requires immediate removal.
5. Check whether the test folder was synchronized or backed up.

If you cannot explain where each copy went, you are not ready to use a sensitive image. Find the missing step first.

Add complexity one risk at a time

After the disposable files work, move gradually:

• a larger harmless file to test memory and speed;
• a supported phone format to test decoding;
• a harmless portrait-like silhouette to test hair edges;
• a public page image to test the right-click route;
• the actual destination application using only the disposable result.

Changing one variable at a time gives you useful evidence. Testing a huge private photo through a new page workflow and pasting it into a new online service all at once does not.

Images that should not be “just a test”

Do not use these unless you have authority, a real need, and an approved handling process:

• identity documents or official application photos;
• medical, financial, or legal records;
• children’s images;
• client assets covered by a contract;
• unreleased products or internal screenshots;
• intimate images;
• security layouts, access credentials, or evidence;
• any image belonging to someone who did not consent.

Local processing is a useful architectural property. It is not permission to ignore ownership, consent, confidentiality, or organizational rules.

Keep a reproducible test note

If the tool will be used by a team, record a small, non-sensitive test note:

• browser and extension version;
• source format and approximate dimensions;
• whether first-run model setup had completed;
• start path: file, paste, drop, or page image;
• export method;
• where local history was found and how it was cleared;
• any visible failure message.

Do not attach a confidential source just to make the note complete. A safe sample that reproduces the behavior is better.

A sensible trust baseline

Safe testing combines three habits: minimize what you expose, observe the complete workflow, and verify cleanup. It complements documentation rather than replacing it.

Read What we do not upload for the scoped data-path claim and Permissions explained for image extensions for the feature-to-access mapping. Then use the actual browser controls and a disposable image to confirm the workflow makes sense on your device.