When you select a photo for an AI face swap, the file does not remain only inside the browser. It must be uploaded, made available to the processing service, associated with a task, and returned as a generated result. Those steps involve several systems and different kinds of records.
This article explains the current faceswap workflow in operational terms. It is a product guide, not a replacement for the Privacy Policy, which controls if this summary and the policy ever differ.
The Short Version
A normal faceswap request follows this path:
- You sign in and choose a target photo.
- Your browser uploads the file to storage configured for faceswap.
- You use the built-in face reference or upload a permitted custom reference.
- faceswap sends the target and reference image locations to PiAPI.
- PiAPI creates a face-swap task and returns a task identifier.
- faceswap records task status and operational execution details.
- When processing succeeds, the output location is returned and may be copied to configured storage.
- The result is shown in your account workflow for review and download.
Closing the browser tab does not automatically reverse those server-side steps.
Step 1: Selecting a File in the Browser
Before upload, the file picker or drag-and-drop interface holds a local reference to the file you selected. At this point, the browser can display a preview without necessarily sending the full file elsewhere.
Once the upload starts, the situation changes. The browser sends the file to the faceswap upload endpoint. The upload route requires an authenticated account.
The current interface focuses on JPG, PNG, and WebP images and displays its active file-size limit. The server also validates file count, size, and media type. A file that is too large or has an unsupported type should be rejected before an AI task is created.
Do not rely on a renamed extension. Changing photo.exe to photo.jpg, for example, does not turn it into an image. Validation and downstream decoding depend on the actual file content and media type.
Step 2: Storage Before AI Processing
The AI provider needs a retrievable target image. The uploaded bytes are therefore stored using the object-storage provider configured for faceswap, currently Cloudflare R2 or another S3-compatible service.
Object storage is different from a temporary browser preview. It creates a server-side object with a storage key and a URL or proxied access path. The application may detect identical uploads and reuse an existing stored object rather than save a duplicate.
Important consequences:
- removing the thumbnail from the browser form may only update the interface;
- closing the tab does not necessarily delete the stored object;
- a file can remain available long enough for processing, delivery, support, and security review;
- storage and backup copies can follow different deletion schedules; and
- the file may retain metadata that was embedded when you uploaded it.
If a photo contains sensitive GPS or device metadata, remove it from a copy before upload. See our JPEG, PNG, WebP, and metadata guide.
Step 3: Target Image and Face Reference
A face swap needs two visual inputs:
- Target image: the scene, body, pose, expression, lighting, and face area to transform.
- Swap or reference image: the identity information that the model applies.
faceswap provides a built-in reference for its standard parody-style workflow. The interface can also allow a custom reference upload. You are responsible for having the rights and consent needed for both images.
The application prepares the target URL and reference URL as task inputs. A URL is necessary because the third-party processing service must retrieve the images. This means that both the target and a custom reference may be disclosed to the AI provider for the requested processing.
Do not use a custom reference that contains unrelated private information in the background. Crop it to the permitted, relevant portrait before upload.
Step 4: Submission to PiAPI
faceswap currently uses PiAPI as its third-party face-swap processing provider. The application sends a task request that identifies the face-swap operation and includes the target and reference image locations.
PiAPI returns a provider task identifier and status. That identifier allows faceswap to ask whether processing is waiting, running, complete, or failed. A provider task is separate from your browser session; it may continue even if you navigate away.
PiAPI processes the images under its own systems, security controls, terms, and privacy practices. faceswap does not control every internal provider retention or diagnostic process. Do not upload highly confidential material merely because the output is intended to be humorous.
Step 5: Task and Execution Records
A reliable service needs more than the final picture. faceswap records information needed to operate the request, which can include:
- the faceswap task’s internal identifier;
- your account identifier;
- provider and model name;
- target and reference options, including stored image locations;
- provider task identifier;
- submission, acceptance, and completion timestamps;
- current status;
- credit cost and whether the task was persisted;
- output location or provider result information; and
- sanitized error, retry, timing, and failure-stage details.
These records help answer questions such as:
- Was the request accepted by the provider?
- Did the failure happen before or after credits were checked?
- Is a task still running or did it fail?
- Which output belongs to which account request?
- Is a recurring error caused by upload, provider configuration, or result delivery?
Operational records do not need to contain your full payment-card number. Payments are handled by the provider shown at checkout, while faceswap stores order and transaction references needed for account and billing support.
Step 6: Status Updates and Output Delivery
After submission, the application can receive a provider notification or query PiAPI for status. When the task succeeds, the provider response includes output information.
If custom storage is enabled, faceswap may download the generated file from the provider and save a copy under its configured object storage. This reduces dependence on a temporary provider URL and allows the result to be delivered through the site’s storage path.
The output is then associated with the task record and shown in the account activity or generator workflow. Depending on system behavior and storage configuration, an output URL can remain available after you close the page.
Download the result you need, but do not treat the account history or an external URL as your only archive. Provider links, account access, and product features can change.
What the AI Provider Can Receive
For a standard request, the provider needs enough information to perform and return the task. That can include:
- target image URL and image content;
- custom or built-in reference image URL and content;
- requested operation and model identifier;
- callback information used for task status;
- provider task identifier; and
- technical request information such as timestamps and network logs generated by the provider.
faceswap does not intentionally need to send your password or complete payment-card details to the AI provider. However, visible text, documents, badges, screens, locations, and other people inside the image are part of the image content and can be processed with it.
Crop or redact irrelevant sensitive content before upload. Redaction should be permanent in the exported copy, not a removable editor layer.
How Long Are Images Kept?
There is no honest single retention number that applies to every copy in the workflow. Retention can differ between:
- the application’s object storage;
- PiAPI’s processing systems;
- generated output storage;
- task and diagnostic records;
- encrypted backups;
- fraud and security records; and
- records that must be kept for accounting, disputes, or legal compliance.
faceswap retains information only as reasonably necessary for service delivery, support, security, disputes, and legal obligations, as described in the Privacy Policy. The current code does not promise that every upload is automatically deleted after a fixed number of hours or days.
That distinction matters. A precise but unimplemented “24-hour deletion” promise would be less protective than an accurate policy and a working request channel.
How to Request Deletion
To request deletion or exercise another applicable privacy right, email support@charliekirkface.net with the subject Privacy Request.
Include enough information to locate the data:
- the email address associated with the account;
- the relevant task identifier or activity date, if available;
- whether the request concerns uploads, outputs, task records, the account, or all applicable data; and
- the country or region relevant to the request, if you are invoking a specific legal right.
Do not email your password, full card number, or a new copy of a sensitive image merely to identify the task. Support may ask for reasonable verification to prevent someone else from deleting your account or records.
Deletion can be limited by legal obligations, payment records, fraud prevention, active disputes, security needs, or technically isolated backups. A verified deletion request also may not instantly remove copies held under an independent provider’s lawful retention schedule.
Account Deletion and Image Deletion Are Not Always Identical
An account contains authentication, activity, credit, order, and task relationships. An image object is stored separately. A payment provider holds transaction records under its own obligations. Deleting one record does not automatically prove that every related copy disappeared at the same instant.
When submitting a request, be explicit about scope. “Delete my account and all personal uploads and outputs that are not legally required” is clearer than “remove my picture.”
If you only want a public or shared output taken down, provide the exact URL and explain the affected right. Use the same support address for privacy, copyright, likeness, or safety reports.
Privacy Checklist Before Upload
Ask these questions before the file leaves your device:
- Do I own the photo or have permission to process it?
- Do I have the consent or lawful basis needed for identifiable people?
- Does the image show a child, private home, medical setting, ID document, financial record, badge, license plate, or computer screen?
- Does the file contain GPS or device metadata I do not want to share?
- Can I crop out unrelated people or private background details?
- Is the custom reference limited to one relevant portrait?
- Would a clearly labeled parody output still create a privacy or safety risk?
- Am I comfortable with the image being handled by application storage and a third-party AI provider?
If the last answer is no, do not upload the image.
Security Without Overpromising
faceswap uses authenticated requests, HTTPS transport, restricted service credentials, and storage-provider controls. Cloudflare R2 and compatible infrastructure provide their own security features. These controls reduce risk but do not make internet transmission or AI processing risk-free.
You can reduce exposure by:
- using a dedicated upload copy;
- removing unnecessary metadata;
- cropping private surroundings;
- avoiding confidential documents and screens;
- protecting your account with a unique password or trusted OAuth provider;
- downloading results only to devices you control; and
- reporting unexpected account activity promptly.
Never publish a storage URL, browser developer log, or support response that contains private task information.
What Closing the Tab Does and Does Not Do
Closing the browser tab:
- stops you from viewing that page;
- may end an in-browser upload that has not completed;
- does not cancel a provider task already accepted;
- does not automatically delete an uploaded object;
- does not erase a saved task record; and
- does not revoke a downloaded or shared copy.
If you submitted the wrong image, check your activity page and contact support with the task details. Do not assume that leaving the page is a deletion action.
Final Takeaway
A face swap is a data-processing workflow, not an entirely local filter. The target and reference move from your browser to application storage, then to PiAPI for processing. Task and execution records connect the request to your account, and generated outputs may be copied to application storage for delivery.
That workflow is why source rights, consent, metadata, retention, and deletion instructions matter before generation, not only after something goes wrong.
Read the full Privacy Policy, Terms of Service, and Content Policy. If the image is appropriate and you accept the processing path, you can continue to the faceswap tool.
