Sending files

How to share BIM models and CAD files with clients

By Hein de Wilde·Updated ·4 min read

Key takeaways

  • Send each issue as one link with its folder tree intact, never as attachments — a flattened xref folder is worse than a late file.
  • Give each project a lasting home instead of expiring links, and collect consultants’ models through an upload link.
  • Download receipts settle “which revision did you have?” before it becomes a dispute.
Contents
  1. Why model files break the usual routes
  2. Send an issue, not a pile of files
  3. Keep a place clients come back to
  4. Getting models back from consultants
  5. Know which revision someone actually has
  6. Files with sensitive detail
  7. A workflow that holds up

The reliable way to share BIM models and CAD drawings with a client is to stop attaching them and stop squeezing them through a shared drive meant for spreadsheets. Put each issue in one place with its folders intact, send the client a link to it, and keep a record of who downloaded which revision. Email breaks at 25 MB; a model set breaks email long before it breaks anything else.

I run Yungle, so I have an interest here. Everything below works whatever service you use, and I say where ours falls short.

Why model files break the usual routes

A single Revit model, an IFC export or a heavy DWG with xrefs is routinely hundreds of megabytes, and a full issue — models, drawing sets, schedules, renders — can run to several gigabytes. That rules out email outright, and it strains the consumer file-sharing tools most practices fall back on.

The size is only half of it. The other half is structure. A DWG that has lost its xref folder, or an issue where the "Superseded" folder got flattened into "Current", is worse than a late file: it is a wrong file that looks right. Whatever you use has to deliver the folder tree exactly as you built it.

Send an issue, not a pile of files

Treat every issue to a client as one package with a name and a date: 2026-09-22 — Stage 4 issue. Inside it, keep the folders the way your office already works:

  • Models/ — the native files and the IFC exports.
  • Drawings/ — PDF sets, which are what most clients actually open.
  • Superseded/ — last issue, clearly separated, if you send it at all.

A client who opens one link and sees that structure does not need a covering email explaining which file is current. A client who receives six attachments across three emails does.

Keep a place clients come back to

The deeper problem with transfer links is that they expire. That is right for a one-off hand-over and wrong for a project that runs eighteen months. The contractor asks for the Stage 3 set in March; the link you sent in October is long dead; someone spends an afternoon finding the right version again.

A project needs a lasting home: one address per project where every issue sits, in order, for as long as the project runs.

On Yungle that is a collection: folders arrive exactly as you uploaded them, clients and consultants open it without an account, and nothing expires unless you give it a date. Guests can view, download, favourite and comment — they cannot upload into it, which is deliberate, and why incoming files go through a request link instead (below).

One honest limit: Yungle previews images, video, audio and PDF in the browser. It does not render Revit, IFC or DWG files — those download as they are. For most clients that is fine, because the PDF set is what they read and the models are what their consultants load.

Getting models back from consultants

The traffic runs both ways. Structural and services consultants send their models back, often at the last minute, often too large for email, and often into whatever folder the person receiving them happened to have open.

A file request fixes the routing: you send one upload link per project, and whatever comes through it lands in the right folder, checked for viruses before it reaches you. The consultant needs no account. The folder is the record of what arrived and when.

Know which revision someone actually has

Most disputes about drawings are not about the drawing. They are about whether someone had the current one. "We built to what you sent" is only answerable if you know what you sent, and whether they downloaded it.

A download receipt answers it: who fetched which issue, and when. It is the difference between "I think I sent it on the 12th" and a line you can point to. On Yungle every transfer records downloads per recipient, and you get an email the moment a file is downloaded.

Files with sensitive detail

Some drawings carry more than geometry: security layouts, plant rooms of critical buildings, a private client's home. For those, two settings matter more than anything else — a password on the link, and an expiry date, so a forwarded link stops working on its own schedule. Secure sharing covers both, and how to send confidential documents is the wider version.

A workflow that holds up

  1. One collection per project, named the way your office names projects.
  2. One folder per issue, dated, with Models/, Drawings/ and, where needed, Superseded/.
  3. One request link per consultant, landing in their own folder.
  4. Passwords and expiry dates on anything sensitive.
  5. Check the receipts before a design meeting, not after it.

If you want to see how a practice would set this up end to end, the page for architects and engineers walks through a week of it. And if you are still at the "how do I get this one big file across" stage, how to send large files is the place to start.

Hein de Wilde

I build and run Yungle, and I write everything here. Comparisons name competitors and credit them, every claim about another company comes from that company’s own documentation, and where we fall short it says so. More about who is behind this.

Read next