Browser compatibility
WebRTC itself works in every modern browser. Where browsers genuinely differ is in how files can be saved — and that changes what we can promise per platform.
Support targets
| Browser | Versions | Transfer | Streamed saving to disk |
|---|---|---|---|
| Chrome / Edge (desktop) | Current and previous stable | Supported | Yes — File System Access API, incl. folder saves |
| Firefox (desktop) | Current and previous stable | Supported | No — falls back to in-memory download (size-capped) |
| Safari (macOS) | Current and previous major | Supported | No — in-memory fallback (size-capped) |
| Chrome (Android) | Current stable | Supported | Partial — depends on Android version |
| Safari (iOS / iPadOS) | Current and previous major | Supported | No — in-memory fallback; background tab suspension applies |
What the fallback means for you
Without streamed saving, a received file is assembled in browser memory before download. We cap this path conservatively and warn you up front rather than letting the tab crash mid-transfer. Practical size guidance per platform lives on the file size and limits page.
Verification status
Our automated end-to-end suite exercises the full transfer flow (room creation, join, accept, transfer, hash verification) on Chromium and WebKit engines, plus the room/invite flows on Firefox; the WebRTC leg on Firefox and physical-device testing on iOS and Android are verified manually and tracked in our release checklist. This page is updated as claims are verified — we would rather under-promise here than list a matrix we have not run.