The best way to send large files to construction and survey clients depends on file size and whether your client needs to view the data or just store it. For files under 2 GB, WeTransfer works in a pinch. For multi-gigabyte spatial data like point clouds, orthomosaics, and 3D models, a purpose-built platform like Swyvl lets you upload once and gives your client browser-based viewing, organised delivery, and an audit trail — without forcing them to download 8 GB of files they cannot open.
I run a spatial data company and talk to surveyors every week who describe the same problem: they spend days capturing and processing data, then hit a wall when it is time to get that data to the client. The files are too large for email, too specialised for Dropbox, and too numerous to send one at a time. This guide covers every realistic option, from the quick fixes to the proper solutions.
Why large file delivery is harder for construction and survey
Construction and survey data is not like sharing a PowerPoint presentation. The files are fundamentally different in three ways:
They are enormous
A single LiDAR scan can be 2-10 GB. An orthomosaic from a drone survey might be 3-8 GB. A photogrammetric 3D model can exceed 15 GB. A typical survey delivery — point cloud, orthomosaic, DTM, contours, video, report — can easily reach 20-30 GB across all deliverables.
They require specialist software to open
LAS and E57 files need CloudCompare or a point cloud viewer. GeoTIFFs need QGIS or ArcGIS. DXF files need AutoCAD or a CAD viewer. IFC files need a BIM application. Your client — a project manager, site engineer, or property developer — almost certainly does not have these tools installed and should not be expected to install them just to see your work.
They need context
A folder containing scan_001.las, ortho_20260410.tif, contours.dxf, and report.pdf tells the client nothing about what each file represents, which capture session it belongs to, or what they should look at first. Spatial data needs spatial context — ideally, a map showing where each dataset was captured.
Method comparison
| Method | Max file size | Viewer included | Branding | Cost | Audit trail | Expiry |
|---|---|---|---|---|---|---|
| Email attachment | 25 MB | No | Your email signature | Free | Read receipts only | No |
| WeTransfer (free) | 2 GB | No | WeTransfer branded | Free | Download count | 7 days |
| WeTransfer Pro | 200 GB | No | Custom background | $15/month | Download tracking | Configurable |
| Dropbox | 2-50 GB per file | PDF, image, video only | None | $12-24/month | Basic view tracking | No |
| Google Drive | 5 TB per file | PDF, image, video only | None | Free-$10/month | View history | No |
| FTP / SFTP | Unlimited | No | None | Server costs | Server logs | No |
| Swyvl | Unlimited | 14 spatial file types | Full white-label | Free tier available | IP + geo tracking | Configurable |
Email: the 25 MB ceiling
Every surveyor has tried emailing a file that was too large. Email attachments are capped at 25 MB for Gmail and Outlook, and 20 MB for some corporate servers. That rules out virtually every spatial file except small PDFs and compressed vector files.
Even when you manage to squeeze a file under the limit by aggressive compression, email is fundamentally the wrong tool. There is no organisation, no viewing, no version management, and searching through old emails for “that scan I sent in March” is miserable for everyone involved.
Verdict: Fine for sending a PDF report. Useless for spatial data.
WeTransfer: quick but limited
WeTransfer solves the immediate problem: you can send files up to 2 GB for free. Upload, enter the recipient’s email, done.
For spatial data, the limitations become apparent quickly:
- 2 GB cap on free tier: A single point cloud exceeds this. Even compressed LAZ files from large scans often hit this limit.
- 7-day expiry on free tier: Your client goes on holiday, comes back, and the link is dead. You resend. They lose it again.
- No viewing: The client downloads a ZIP file and is back to the “I can’t open this” problem.
- No organisation: Each transfer is independent. There is no way to group files by project or session.
- WeTransfer branding: Your professional survey delivery arrives in a WeTransfer wrapper.
WeTransfer Pro raises the limit to 200 GB and removes the expiry, but still offers no file viewing and minimal branding.
For a detailed comparison, see survey data delivery: the WeTransfer problem.
Verdict: Acceptable for a one-off transfer of a small file. Not a delivery solution.
Dropbox and Google Drive: storage without viewing
Cloud storage platforms solve the size problem. You can upload multi-gigabyte files, organise them in folders, and share a link. Your client can download files at their convenience without expiry pressure.
The problem is what happens after download. Dropbox and Google Drive can preview PDFs, images, and video. They cannot preview LAS, LAZ, E57, GeoTIFF, OBJ, DXF, IFC, or any other spatial format. Your client downloads 8 GB of files, opens the folder on their desktop, and sees a collection of files with unfamiliar extensions.
I have written extensively about this in why surveyors are ditching Dropbox. The core issue is that Dropbox and Google Drive are file storage tools, not data delivery tools. They solve the transfer problem while completely ignoring the viewing problem.
Other limitations for spatial data:
- No spatial context: Files are listed alphabetically, not organised by capture session or shown on a map.
- No branding: Your delivery looks like a Dropbox folder, not a professional deliverable from your company.
- Storage limits: Free tiers are small (2 GB Dropbox, 15 GB Google Drive). Paid plans add cost that scales with data volume.
- No specialised audit trail: You get “someone viewed this folder” but not “the site engineer viewed the point cloud for 12 minutes and then downloaded the contours.”
Verdict: Fine as supplementary storage for non-spatial files (reports, photos). Not a primary delivery mechanism for spatial data.
FTP and SFTP: the technical barrier
FTP (File Transfer Protocol) and its secure variant SFTP have no file size limits and have been used for large file transfers for decades. Some surveying firms still maintain FTP servers for client data delivery.
The problems are well-known:
- Technical barrier for clients: Your client needs an FTP client (FileZilla, Cyberduck) or needs to navigate browser-based FTP, which is inconsistent across browsers. Non-technical clients find this intimidating.
- No viewing: FTP is purely a file transfer protocol. No previews, no viewers, no metadata.
- Server maintenance: You need to run and maintain an FTP server, manage user accounts, monitor storage, and handle security patches.
- No branding or organisation: It is a directory listing. Nothing more.
- Security concerns: Standard FTP transmits credentials in plain text. SFTP fixes this but adds configuration complexity.
Verdict: Still used in some government and infrastructure contexts where it is mandated. Not recommended for general client delivery in 2026.
Purpose-built spatial delivery platforms
The category that actually solves the problem: platforms designed specifically for sharing spatial data with clients who do not have specialist software.
Swyvl is the platform I built to address this exact pain point. You upload your survey deliverables — LAS point clouds, GeoTIFFs, 3D models, DXF drawings, video, 360 photos, PDFs — and the platform automatically classifies each file, generates thumbnails, and assigns the appropriate browser-based viewer.
Your client receives a branded share link. They click it and see every deliverable with a working viewer. Point clouds render in Potree. Orthomosaics display on a Leaflet map as Cloud Optimized GeoTIFFs. 3D models load in Three.js. CAD drawings render in a DXF viewer. No downloads required for viewing. No software to install.
Files are grouped by capture session and shown on a map, so a construction client with monthly surveys can see each session in chronological order and understand what was captured where.
The audit trail tracks who accessed the share link, what they viewed, what they downloaded, and when — with IP and geolocation data. This matters for compliance and for the practical reality of “the client says they never received the data.”
Recommendations by project size
Small project (under 2 GB total, few file types)
If you are delivering a single PDF report and a few photos from a small boundary survey, email or WeTransfer is perfectly adequate. The files are small, the client can open them, and the overhead of a platform is not justified.
Medium project (2-10 GB, mixed file types)
This is where generic tools start to fail. A typical drone survey producing an orthomosaic, point cloud, and video will hit 5-8 GB. Your client needs to view the orthomosaic and point cloud, not just download them.
Use a purpose-built platform for the spatial files and attach the PDF report to your delivery email. The spatial files get proper viewers, the report gets read in the email client, and everyone is happy.
Large project (10+ GB, multiple sessions, multiple stakeholders)
Construction monitoring projects, infrastructure surveys, and mining operations produce enormous volumes of data across multiple capture sessions. A platform with session-based organisation, audit trails, and team access controls is essential.
At this scale, the platform pays for itself in time saved. Resending expired WeTransfer links, answering “how do I open this file” emails, and manually tracking who has accessed what — these tasks consume hours every month that a proper delivery platform eliminates entirely.
The real cost of the wrong approach
The financial cost of WeTransfer Pro or a Dropbox subscription is trivial. The real cost of using the wrong delivery method is measured in:
- Client perception: A Dropbox folder full of files the client cannot open does not inspire confidence in your technical capability.
- Support time: Every “how do I open this LAS file?” email costs you 15-30 minutes of explanation, often followed by “I installed CloudCompare but it crashed.”
- Repeat business: Clients who can actually see and interact with your data understand its value. Clients who receive an impenetrable ZIP file do not.
- Compliance risk: “When did the client access the data?” is a question you should be able to answer definitively, not guess at based on email timestamps.
Getting started
If you are currently using Dropbox or WeTransfer for spatial data delivery, the migration path is straightforward:
- Sign up for a Swyvl account and create your first site.
- Upload the deliverables from your next project.
- Generate a share link and send it to your client alongside your usual delivery email.
- Check the audit trail to see when and how your client interacts with the data.
The first time your client says “I can see the point cloud right in my browser” instead of “I can’t open this file,” you will understand why purpose-built delivery tools exist.
For more on professional delivery workflows, see the surveyor’s guide to professional file delivery.