DirectFileTransfer.com

Secure P2P file sharing No cloud storage Fast & unlimited

About DirectFileTransfer

Secure, private peer-to-peer file sharing

What is DirectFileTransfer?

DirectFileTransfer is a secure peer-to-peer file sharing platform that enables you to send files directly from one device to another without using any cloud storage. Your files never touch our servers—they transfer directly between devices using encrypted WebRTC technology with built-in security features including password protection, one-time use links, and verification codes.

How P2P File Transfer Works: Direct connection between sender and receiver with signaling server coordination

Key Features

Security Features: Password Protection, One-Time Use Links, and Verification Codes

🔒 Password Protection

Secure your file transfers with SHA-256 encrypted passwords.

🔑 One-Time Use Links

Create links that expire after first use for maximum security.

✅ Verification Codes

6-digit codes ensure you're connected to the right person.

🛡️ Privacy First

Files never stored on servers. Direct device-to-device transfer.

⚡ No Size Limits

Transfer files of any size without restrictions.

🌐 Works Anywhere

Transfer across networks, countries, and platforms.

📱 Mobile Friendly

Works seamlessly on phones, tablets, and computers.

🚀 No Registration

Start sharing immediately without creating an account.

💰 Completely Free

No subscriptions, no hidden fees, no paywalls.

Encryption & Security Details

Complete transparency about how we protect your data:

🔐 WebRTC Encryption (DTLS-SRTP)

Algorithm: All file transfers use WebRTC's built-in DTLS-SRTP encryption protocol, which provides:

  • DTLS 1.2/1.3 - Datagram Transport Layer Security for secure connection setup
  • SRTP - Secure Real-time Transport Protocol for encrypted data channels
  • AES-128-GCM or AES-256-GCM - Industry-standard symmetric encryption for actual file data

🔑 Key Management

Automatic Key Exchange: WebRTC uses DTLS handshake to establish encryption keys:

  • Keys are generated automatically by your browser during connection setup
  • Keys never leave your device or pass through our servers
  • Each connection gets unique encryption keys (Perfect Forward Secrecy)
  • Keys are destroyed immediately when the connection closes

🔒 Password Security (SHA-256 Hashing)

When you enable password protection:

  • Passwords are hashed using SHA-256 algorithm in your browser
  • Only the hash (not the actual password) is sent to the signaling server
  • The receiver's password is also hashed and compared server-side
  • Your actual password never travels over the network in plain text

📡 What Our Server Sees

Zero Knowledge Architecture:

  • Signaling Server: Only sees encrypted WebRTC handshake data (ICE candidates, SDP offers/answers)
  • File Contents: Never touch our servers - they go directly peer-to-peer
  • Password Hashes: We only store SHA-256 hashes temporarily during room lifetime
  • Metadata: Room ID visible for connection coordination
  • Limited Logging: IP addresses logged temporarily in server logs for debugging—file contents and transfer history never logged

⚠️ If Transfer is Interrupted

What Happens:

  • Partial Data: Any data already transferred is saved to the receiver's device
  • Resume Not Available: Currently, interrupted transfers cannot be resumed (planned for future)
  • Connection Lost: Both parties are notified immediately when peer disconnects
  • Security: All encryption keys are destroyed when connection drops
  • Restart Required: You'll need to initiate a fresh transfer with new encryption keys

🛡️ Network Security (STUN/TURN)

NAT Traversal:

  • Uses Google's public STUN servers to establish direct connections
  • TURN relay servers may be used if direct connection fails (traffic still encrypted)
  • Even when relayed, only encrypted data passes through relay servers
  • No relay server can decrypt your file contents

🔍 Open Source & Auditable

Transparency:

  • Built on open web standards (WebRTC, DTLS, SRTP)
  • Browser implementations are audited by security researchers worldwide
  • You can inspect the network traffic using browser DevTools
  • All encryption is handled by your browser's native WebRTC implementation

How It Works

5-Step Transfer Process: Select, Secure, Generate, Share, and Transfer
1

Select a File

Choose the file you want to share from your device.

2

Set Security Options

Optionally enable password protection and one-time use links for added security.

3

Generate Share Link

Create a unique sharing link and get a 6-digit verification code.

4

Share & Verify

Send the link and verification code to your recipient. They'll enter the password if required.

5

Transfer Files

Once connected and verified, files transfer directly between devices with end-to-end encryption.

Frequently Asked Questions

Is my data secure?

Yes. Files transfer directly between devices using encrypted WebRTC connections with end-to-end encryption. We never see or store your files. You can add extra security with password protection and one-time use links.

What is the verification code for?

The 6-digit verification code ensures both sender and receiver are connected to the right person. Simply verify that both parties see the same code before starting the transfer—similar to Bluetooth pairing codes.

How does password protection work?

Passwords are hashed using SHA-256 encryption before being sent to the server. Receivers must enter the correct password to join the room. The actual password never leaves your device in plain text.

What are one-time use links?

One-time use links expire after the first successful file transfer, preventing anyone else from reusing the link. Perfect for sensitive files you want to share with only one person.

Do both devices need to be online?

Yes. Since transfers are peer-to-peer, both sender and receiver must be connected simultaneously.

Is there a file size limit?

No. You can transfer files of any size, though larger files will take longer depending on your internet connection speed.

Does it work on mobile?

Yes. DirectFileTransfer works on all modern browsers including mobile Safari, Chrome, and Firefox.

Performance, Reliability & Limitations

⚡ Transfer Speed & Network Dependency

P2P Reality: Since transfers are peer-to-peer, performance depends on:

  • Upload Speed: Limited by sender's upload bandwidth (typically slower than download)
  • Download Speed: Limited by receiver's download bandwidth
  • Network Conditions: Both parties must have stable internet connections
  • Geographic Distance: Longer distances may add latency but not significantly affect speed
  • Simultaneous Presence: Both sender and receiver must be online at the same time

Expected Speeds: Typically 1-10 MB/s depending on network quality. Large files (GB+) may take minutes to hours.

🔥 Firewall & NAT Issues

Connection Challenges:

  • Corporate Firewalls: Some corporate networks block WebRTC connections—try from home network if transfer fails
  • Strict NAT: Restrictive routers may prevent direct connections—system automatically falls back to TURN relay servers
  • VPN Impact: Some VPNs may interfere with P2P connections—disable if experiencing issues
  • Fallback: When direct connection fails, traffic routes through Google's TURN servers (still encrypted)

❌ What Happens if Transfer is Interrupted?

Current Behavior (v1.0):

  • Partial File: Receiver gets incomplete file—you'll need to restart the entire transfer
  • No Resume: Currently no resume capability—planned for future versions
  • No Recovery: If connection drops, both parties must reconnect and start fresh
  • Checksums: No automatic file verification yet—manually verify file integrity after transfer
  • Best Practice: For critical large files, use stable wired connections and verify file completeness

⚠️ Important: For mission-critical transfers, we recommend using traditional cloud storage with retry/resume capabilities. DirectFileTransfer is best for quick, secure transfers where both parties can stay connected.

🔍 File Integrity & Checksums

Current Status:

  • No Built-in Verification: System doesn't automatically generate/verify checksums (planned for v2.0)
  • Manual Verification: After transfer, compare file sizes to ensure completeness
  • WebRTC Reliability: Transport layer includes error detection but not end-to-end file hashing
  • Recommendation: For sensitive files, manually verify with SHA-256/MD5 tools after transfer

Data Retention, Logs & Privacy

📊 What Data We Store

Complete Transparency:

  • File Contents: NEVER stored—files transfer directly peer-to-peer
  • Room Metadata (Temporary): Room ID, password hash, verification code—deleted when room closes
  • IP Addresses: Logged in server logs for debugging/connection purposes—retained for a limited period
  • Transfer Logs: Connection events logged temporarily for debugging—no file content or metadata
  • Analytics: Anonymous usage statistics (via Google Analytics)—no personally identifiable information

🗑️ Data Deletion Policy

Automatic Cleanup:

  • Room Data: Deleted immediately when both peers disconnect
  • Password Hashes: Removed when room is destroyed
  • Connection Logs: Cleared every 24 hours
  • No Permanent Storage: We don't maintain databases of past transfers, users, or files

🔗 Link Security & Interception Risks

Important Security Considerations:

  • Link Interception: Anyone with the link can attempt to join the room—ALWAYS use password protection for sensitive files
  • Share Securely: Send links via encrypted channels (Signal, WhatsApp, encrypted email) not SMS or public posts
  • One-Time Use: Enable one-time use links to prevent link reuse after transfer
  • Verification Codes: Always verify the 6-digit code verbally/via separate channel before transferring sensitive data
  • Strong Passwords: Use 12+ character passwords with mix of letters, numbers, symbols for maximum security
  • Link Expiry: Links become invalid once both parties disconnect—no persistent access

🚨 Security Warning: Treat share links like passwords. Anyone with the link can join before you connect. For maximum security: 1) Enable password protection 2) Enable one-time use 3) Verify the 6-digit code 4) Share link via secure channel only.

Known Limitations & Future Roadmap

⚠️ Current Limitations (v1.0)

  • No Resume/Retry: Interrupted transfers must restart from beginning
  • No File Verification: No automatic checksum generation or verification
  • No Multi-File: Can only send one file at a time (no batch transfers)
  • No Mobile App: Browser-only (no native iOS/Android apps)
  • No Persistent Rooms: Rooms close when peers disconnect—no "save for later"
  • No Compliance Certs: Not certified for HIPAA, SOC 2, ISO 27001, etc.
  • No Customer Support: Best-effort support via GitHub issues only

🚀 Planned Features (v2.0+)

  • Resume Capability: Ability to resume interrupted transfers
  • Checksum Verification: Automatic SHA-256 hash generation and verification
  • Multiple Files: Send folders or multiple files at once
  • Transfer History: Local browser history of your transfers (never stored on server)
  • QR Code Sharing: Generate QR codes for easy mobile sharing
  • Speed Optimization: Improved chunking algorithms for faster transfers
  • Mobile Apps: Native iOS and Android applications

Ownership, Trust & Transparency

👤 Who Owns & Operates This Service?

Service Information:

  • Type: Open-source personal project, not a registered business entity
  • Operator: Independent developer (no corporate backing or investors)
  • Location: Service operated from India, hosted on Google Cloud Platform (US region)
  • Purpose: Educational project and free community tool—not commercial venture
  • Contact: Issues and questions via GitHub repository only

⚠️ Transparency Note: This is NOT a commercial service with dedicated support team or SLAs. It's a free, best-effort project. Use accordingly.

📋 Terms of Service & Privacy Policy

Legal Framework:

  • Terms of Service: Available at /terms.html (basic acceptable use policy)
  • Privacy Policy: Available at /privacy.html (details data handling practices)
  • No Legal Entity: Service operated by individual, not registered company
  • No Liability: Service provided "as-is" without warranties or guarantees
  • User Responsibility: You agree to comply with all applicable laws when using service

💰 Business Model & Monetization

How We're Funded (Spoiler: We're Not):

  • 100% Free: No subscriptions, no premium tiers, no paywalls—ever
  • No Advertisements: No ads, no tracking pixels, no affiliate links
  • No Data Harvesting: We don't sell data (we don't even have data to sell!)
  • Personal Project: Operated at operator's expense as learning/community contribution
  • Open Source: Code available on GitHub for transparency and community contributions
  • Hosting Costs: Minimal (~$20/month) covered personally—no VC funding or monetization plans

Future Sustainability: If hosting costs become unsustainable, service may move to donation model or community hosting. Users will be notified 90 days in advance of any changes.

🔍 Zero-Knowledge Architecture

What We CAN and CANNOT Access:

  • ✅ Cannot Access: File contents (they never touch our servers)
  • ✅ Cannot Access: Your passwords (only hashed with SHA-256)
  • ✅ Cannot Decrypt: WebRTC encrypted connections (keys stay on your device)
  • ✅ Cannot See: File names or file sizes (not transmitted to server)
  • ❌ Can See: Room IDs (needed for connection coordination)
  • ❌ Can See: Connection events (for debugging—deleted after 24 hours)
  • True Zero-Knowledge: For file contents and metadata—yes. Only minimal connection data needed for signaling.

💡 Technical Reality: Pure zero-knowledge is impossible for P2P signaling—we need minimal metadata to connect peers. However, your actual file data is never accessible to us.

Uptime, Support & Reliability

⏱️ Service Uptime & Maintenance

Current Status:

  • Target Uptime: 99%+ (best effort, no SLA)
  • Hosting: Google Cloud Run (auto-scaling, high availability)
  • Maintenance Windows: Updates deployed with minimal downtime (typically <5 minutes)
  • Monitoring: Basic uptime monitoring—no 24/7 NOC or pager duty
  • Outages: Announced via status page (if available) or GitHub

⚠️ Reality Check: This is a personal project, not AWS. Expect occasional downtime for updates or issues. No guaranteed uptime.

🆘 Support Channels

How to Get Help:

  • GitHub Issues: Primary support channel—report bugs, request features
  • Documentation: This About page, FAQ, and inline help text
  • Response Time: Best effort (typically 24-72 hours for GitHub issues)
  • No Phone/Email: No dedicated support email or phone number
  • Community Support: Users may help each other via GitHub Discussions

Enterprise Support: Not available. This is a free community service without commercial support options.

⭐ User Reviews & Testimonials

Where to Find Feedback:

  • GitHub Stars: Check repository star count and community engagement
  • Issue Tracker: Read open/closed issues to see common problems and resolutions
  • No Formal Reviews: Service not listed on Trustpilot, G2, Capterra, etc.
  • Early Stage: Project is relatively new—limited user testimonials available
  • Try It Yourself: Best way to evaluate—test with non-sensitive files first

🔄 Active Maintenance & Development

Project Activity:

  • GitHub Activity: Check commit history and recent updates
  • Security Patches: Dependency updates and security fixes applied regularly
  • Feature Development: Ongoing—see roadmap section above
  • Abandonment Risk: Moderate—personal project dependent on single maintainer's availability
  • Open Source: If abandoned, community can fork and continue development

File Limits, Performance & Technical Specs

📊 File Size & Transfer Limits

Technical Limitations:

  • File Size Limit: NONE (technically unlimited—limited only by browser memory for files >10MB, on-demand reading for larger files)
  • Transfer Speed: 1-10 MB/s typical (depends on your upload/download speeds)
  • Concurrent Transfers: One file at a time per room
  • Room Limit: Unlimited rooms can be created (no quota)
  • Number of Files: Unlimited transfers per session (sequential, not batch)
  • Browser Limits: Some browsers may struggle with files >2GB due to memory constraints

🔀 Transfer Architecture (P2P vs Server)

How Data Flows:

  • File Data: 100% peer-to-peer (never touches our servers)
  • Signaling Only: Our server only facilitates connection setup (WebRTC handshake)
  • Direct Connection: Once established, data flows directly between devices
  • TURN Fallback: If direct fails, uses Google TURN servers as relay (still encrypted)
  • Speed Advantage: Direct P2P = faster than server-mediated transfers
  • Privacy Advantage: No server storage = no data breach risk

🌐 Network Requirements

What You Need:

  • Internet: Both parties need active internet connection (any speed works, faster = better)
  • Browser: Modern browser (Chrome, Firefox, Safari, Edge—WebRTC support required)
  • Firewall: WebRTC ports accessible (most home networks work fine)
  • NAT: Symmetric NAT may require TURN relay (automatic fallback)
  • Mobile Data: Works on cellular networks (consumes data—use WiFi for large files)

Hidden Risks & Considerations

⚠️ Risks of Using This Service

🚨 Important: Every service has risks. Here's what you should know before using DirectFileTransfer:

  • Single Maintainer Risk: Project depends on one person—may be abandoned if maintainer becomes unavailable
  • No SLA/Guarantees: Service could go offline at any time without notice (unlikely, but possible)
  • Limited Documentation: Not as thoroughly documented as commercial services
  • No Insurance: If files fail to transfer, no recourse or compensation
  • Security Audits: No third-party security audits (code is open source for community review)
  • Compliance Gaps: Not suitable for regulated industries (see compliance section above)
  • Browser Dependence: Entirely dependent on browser WebRTC implementations—browser bugs affect service
  • No Backup: If transfer fails, no server-side backup to retry from

✅ Risk Mitigation Strategies

How to Use Safely:

  • Test First: Try with non-sensitive files before critical transfers
  • Use Passwords: Always enable password protection for sensitive files
  • Verify Codes: Confirm 6-digit codes before transferring confidential data
  • Stable Connection: Use wired internet for large/important files
  • Keep Original: Don't delete source file until recipient confirms successful download
  • Manual Verification: Compare file sizes after transfer to ensure completeness
  • Have Fallback: For critical transfers, have alternative method ready (email, cloud, etc.)
  • Stay Updated: Watch GitHub repository for security updates

🔮 Service Longevity & Sustainability

Future Outlook:

  • Current Plan: Maintain service indefinitely as personal project
  • Hosting Costs: Currently sustainable (~$20/month personal expense)
  • If Costs Increase: May move to donations, Patreon, or community hosting
  • If Discontinued: 90-day notice will be provided to users
  • Open Source Continuity: Code available for others to host if needed
  • No Sunset Plans: No current plans to discontinue service

📞 When NOT to Use This Service

Better Alternatives For:

  • Mission-Critical Files: Use enterprise services with SLAs (Dropbox Business, Box, OneDrive)
  • Regulated Data: Use HIPAA/SOC2-certified services (Tresorit, Sync.com)
  • Large Team Collaboration: Use Google Drive, SharePoint, or enterprise DAM systems
  • Long-Term Storage: Use cloud storage—this is for instant transfer only
  • Unstable Networks: Use services with resume capability (WeTransfer, Send Anywhere)
  • Legal Evidence: Use services with audit trails and chain of custody
  • 24/7 Support Needed: Use commercial services with dedicated support teams

Ready to Share?

Start transferring files securely in seconds

Get Started