Frequently asked questions

The WolfP2P server—no. The WolfP2P browser client running locally in your tab—yes, but only to perform the transfer you requested and within permissions controlled by your browser.

WolfP2P is a multi-layer application. In simple terms, one part runs on your device and another, much smaller part runs on the WolfP2P server:

• The WolfP2P browser client reads the files you select, prepares the offer, sends or receives file metadata, streams the accepted file bytes, and writes received files to the destination you choose. This work stays under the browser's permissions on the participating devices.
• The coordination server establishes and maintains the temporary tunnel. It processes only the coordination data described in What the WolfP2P server sees. It does not receive file bytes or file metadata.

The other participant's browser client receives the files and the file metadata needed to save them. Therefore, “the server cannot read my files” does not mean that no part of WolfP2P processes them: the browser clients must process them, while the coordination server remains outside the file-data path.

No. The browser peers stream file bytes through their encrypted WebRTC connection. The WolfP2P server coordinates the connection but does not store or proxy the files; see what the server does not learn.

No. File names, folder names, paths, extensions, media types, individual file sizes, manifests, and file hashes are excluded from the server-side transfer record and analytics.

The coordination server processes coordination data: the tunnel code and lifecycle, participant roles, temporary server identifiers and reclaim credentials, connection times, IP addresses, and signaling needed to establish the direct connection. Coordination receives final outcomes, not a transfer-progress heartbeat. Optional, consent-controlled volume analytics are a separate purpose and do not govern deadlines. Operational records may also contain request details, rate-limit events, coded failures, and errors. See What the WolfP2P server sees for the complete explanation.

Authorized WolfP2P personnel and contracted service providers may access information held in WolfP2P-operated systems when needed to operate, secure, or support the service. File contents, file metadata, browser-local settings, and local reports are not available through the coordination server because they are not stored there. See the Privacy Notice for the services and data categories involved.

The other participant's browser client receives the file metadata needed to review and save the selected items, including file names, relative folder paths, and sizes. Verification information also passes through the direct connection as required by the transfer. Do not share an invitation or offer files to someone who should not see that information.

They are stored in this browser profile, using browser storage such as IndexedDB and local storage. They are not an account-backed cloud history and do not automatically appear in another browser or device. See Cookies and browser storage for details.

Deleting or clearing the profile's site data can remove its settings, consent state, local identifiers, saved handles, activity history, and reports. It does not recall files already transferred or delete copies held by another participant. A privacy deletion request is a separate process for data associated with the browser profile on WolfP2P systems; see Your privacy choices.

Yes. WebRTC encrypts the data channel between the two browsers. Encryption protects the transfer in transit, but you must still verify that you joined with the intended participant.

Yes. After the connection is established, the browser clients act as browser peers and stream file data through their WebRTC connection rather than through WolfP2P storage. The coordination server remains part of the wider WolfP2P service, but it is not in the file-data path.

Yes. The server relays signaling information, including SDP and ICE data, so the browsers can establish the peer connection. That information can contain network details, but not file contents or file names. See the connection-setup boundary.

No. Direct encrypted transport does not authenticate the other person by itself. The coordination service relays signaling, and the current service does not provide independently authenticated signaling or out-of-band identity verification.

No. It is a temporary means of joining a tunnel, not proof of a person's identity. Share it through a trusted channel and confirm the participant independently when the transfer matters.

WolfP2P limits tunnel participation and applies service protections, but a code is still a secret invitation rather than an identity credential. Keep it private, do not post it publicly, and create a new tunnel if you think it was exposed.

No. The WolfP2P browser client reads the selected file bytes to transfer and verify them, but it does not scan them for malware. The coordination server does not receive or scan the file contents. Use suitable security tools and accept files only from people you trust.

No. WolfP2P is designed to work in a compatible browser without an account or a separate application installation.

One participant creates a tunnel and shares its invitation. The other opens that invitation and joins. WolfP2P uses the coordination service to admit the two participants and help their browsers establish the direct connection.

The participant who opens the transfer offer selects and sends the files; the other participant receives them. Check the role shown in the interface before selecting files or a destination.

Yes. WolfP2P is a live peer-to-peer transfer, not an upload-and-collect service. Both browsers must remain available while the transfer is active.

No. A tunnel is for two participant seats. It is not a group-sharing room.

The current transfer profile supports one file set per tunnel. Create a new tunnel for another set.

Yes, when the browser exposes the required folder-selection capability. Browser support and permission behavior vary; see Browser compatibility.

WolfP2P preserves supported relative paths so the receiver can reproduce the selected folder structure. It does not send an absolute path from the sender's device.

WolfP2P transfers file bytes; it is not a media converter or compression service. Any verification result applies to the bytes transferred by the supported workflow.

Often, yes, but operating systems have different naming and filesystem rules. A name or path valid on the sender's device may be unsafe or unsupported on the receiver's destination.

The browser may omit entries it cannot safely read or represent. WolfP2P reports omissions by reason without sending the omitted file names to the server. Review the offered and completed counts before relying on the result.

Yes. The receiver grants access to a writable destination folder. The current receiver cannot accept files without that capability and has no browser-download fallback.

Do not assume it will. Conflict behavior depends on the browser, destination capability, and transfer mode. Review the interface decision and the final result, and keep backups of important files.

The participants may reconnect and recover when the browser still has the required local state and file access. WolfP2P reports verified progress; it does not guess which bytes survived an interruption.

Sleep can pause or break the browser and network connection. Wake the device, return to the transfer, and follow any recovery guidance shown. Keep both devices awake for the most reliable result.

Closing the active tab ends its live participation and may end the tunnel. Local records can help explain what happened, but they are not a server-held copy of the transfer.

A reload interrupts the active browser session. Recovery may be possible when WolfP2P can reclaim the local participant state and regain the necessary file or destination access, but it is not guaranteed in every browser and mode.

Safe mode prioritizes verified recovery and conservative file handling. It may use temporary browser storage and additional verification before a completed file is committed to its destination.

Quick mode writes through the browser's available destination flow with less recovery protection. It can reduce temporary-storage demands, but an interruption may require more work to restart or verify.

No. Choose the mode before the transfer begins. Changing the file-handling strategy mid-transfer would make recovery and completion claims ambiguous.

It uses the supported recovery evidence for that mode, such as path and size checks plus cryptographic verification where required. It resumes only from progress it can justify; otherwise it restarts the affected work.

Support depends on WebRTC plus the browser APIs needed for the selected workflow. Compatible Chromium-based browsers provide the fullest folder and destination capabilities; other browsers may use reduced flows. Check Browser compatibility before an important transfer.

The current release offers transfers on computers. When WolfP2P identifies a phone or tablet, it asks you to open the same link on a computer; public information remains available.

The browser requires your permission before a site can read selected source files or write to a chosen destination. WolfP2P requests access for the local transfer workflow; the permission does not upload that folder to the server. The local access boundary explains what remains inaccessible.

No. The browser grants access to the local page. The server does not receive the folder handle, absolute path, listing, or contents. Only information deliberately sent through the peer connection reaches the other participant.

Not necessarily. WolfP2P may remember a browser-local handle name, but the browser controls the underlying permission and may ask again after a restart, update, site-data change, or permission reset.

Safe mode may stage incoming data locally so it can verify and recover work before committing the result. Large transfers therefore need enough browser-managed temporary storage as well as enough space at the destination.

No. Reports and activity history are local to the browser profile that recorded them. WolfP2P currently has no account service that synchronizes them across devices.

Use the service lawfully, have the right to send the files, confirm the intended participant and destination, protect the invitation, review counts and sizes, keep appropriate backups, and verify the received result. This summary does not replace the Terms of Service.

No. Possession alone may not give you the right to disclose or transfer a file. You need the necessary ownership, permission, authority, and lawful purpose.

Do not use WolfP2P for unlawful material, malware, abuse, harassment, fraud, privacy violations, infringement, unauthorized disclosure, interception, security bypass, or harmful interference with the service. The full rules are in the Terms of Service.

Only if you have assessed the applicable obligations and WolfP2P's controls are sufficient for your use. Direct encryption does not by itself satisfy every legal, contractual, identity, retention, auditing, or compliance requirement.

No. It is not storage, backup, synchronization, hosting, or unattended delivery. Keep the source until the receiver has verified the result, and maintain independent backups of important data.

Creating or joining a tunnel after the notice means you agree to the Terms and acknowledge the Privacy Notice. If you do not agree, do not use the service.

You must not use WolfP2P if you are under 13. If you are a minor where you live, a parent or legal guardian must review and agree to the Terms for you.