You processed it in WebODM.
Now how do you deliver it?

Short version: WebODM writes eight or nine assets to disk, of which your client can realistically use two. This page walks through which files WebODM actually produced, which of them belong in a delivery, how to make each one openable by someone without GIS software, and how to hand the whole thing over as one address instead of six attachments.

The problem is not processing. It is the last 10 metres.

Your task finished. The WebODM dashboard shows a green bar, an orthophoto you can pan around, a point cloud, a textured model. It looks finished. It is not delivered.

Everything you are looking at lives at http://localhost:8000 — an address that exists only on the machine that ran the processing. Your client cannot open it. Not from their office, not from their phone, not tomorrow. The moment you want someone else to see this, you have to decide what actually leaves your computer, in what shape, and how they will open it.

That decision is the whole job, and it is where most deliveries fall apart: the pilot zips the output folder, drops 4 GB on WeTransfer, and calls it a hand-over.

Step 1 — Know what WebODM actually wrote to disk

Open your finished task and use Download Assets. That dropdown is a map of everything the processing produced. On disk the same files sit under the project directory in these folders:

Sizes are order-of-magnitude for a typical 200 – 800 image mission and scale with your GSD. Folder names come from OpenDroneMap's output structure; if you run a different WebODM version, open Download Assets and check the list against this table before you rely on it.

Step 2 — Decide who each file is for

Three different people want three different things out of the same task, and confusing them is the single most common delivery mistake:

• The client who commissioned the flight. Wants to see the site, understand what you found, and show it to someone else. Needs a viewer and a report. Has no GIS software and never will.
• The surveyor, architect or engineer next in line. Wants georeferenced data to work with: the orthophoto as GeoTIFF, the DSM, sometimes the point cloud. Needs the coordinate system stated explicitly.
• You, in eighteen months. Wants the full output plus the processing settings, so a repeat flight is comparable. That is an archive, not a delivery.

Sending all.zip to the first person is not generosity, it is offloading your job onto them. They will open it, find a .laz they cannot read, and email you asking what to do with it.

Step 3 — Make the orthophoto openable by a human

A 3 GB GeoTIFF is a working file, not a deliverable. Windows Photo Viewer will not open it. It has three realistic destinations, and you often want more than one:

1. Keep it interactive. The version your client actually wants is the one they can pan and zoom, exactly as you see it in WebODM's own map tab. That means serving tiles, not a file — covered in step 5.
2. A Cloud Optimized GeoTIFF for the technical recipient. A COG streams instead of downloading whole, so QGIS opens it without a 20-minute wait:

   gdal_translate -of COG -co COMPRESS=DEFLATE \
     odm_orthophoto.tif ortho_cog.tif

3. A flat image for everyone else. A downsampled JPEG or PNG that opens on any phone, for the email, the report cover, the site meeting:

   gdal_translate -of JPEG -outsize 4000 0 -co QUALITY=88 \
     odm_orthophoto.tif ortho_preview.jpg

Whichever you send, state the coordinate reference system (the EPSG code) and the GSD in cm/pixel in writing. A GeoTIFF without a stated CRS is a photo, not a survey product, and the person receiving it has no way to verify what you assumed.

Step 4 — Decide what happens to the point cloud and the 3D model

The point cloud. odm_georeferenced_model.laz is the rawest thing WebODM produces and almost never belongs in a client delivery. If a surveyor did ask for it, send the LAZ with three things written down: the EPSG code, the vertical datum, and whether it is classified. Without those it is unusable and it will come straight back to you.

The textured model. The OBJ is three files that must stay together — the .obj, its .mtl, and the texture images. Send one without the others and your client opens an untextured grey blob. For anything web-facing, convert to glTF/GLB first, or publish the model to a viewer and hand over the embed instead of the geometry.

The general rule: if opening the file requires software your client does not have, you have not delivered a result — you have delegated a problem.

Step 5 — The trap: WebODM's own share link

WebODM can make a task public and give you a URL to its map and 3D views. On the face of it that solves everything. Two catches decide whether it does:

• A local install is not reachable. If WebODM runs in Docker on your own machine, the public link points at localhost or a LAN address. It works perfectly on your screen and not at all on your client's. This is the single most common reason a "shared" WebODM link arrives dead.
• Exposing the instance is a decision, not a detail. Making it reachable from the internet means putting your processing server online, with your other clients' tasks on it. That is a security and confidentiality question before it is a convenience one.

WebODM Lightning changes the first point — it is hosted, so a public task link genuinely opens for anyone. It does not change the second half of the job: the report, the photos and the context still live somewhere else, and your client still ends up with several links.

Step 6 — Bundle it into one delivery

By this point you have made your choices: a viewer for the map, possibly a 3D model, a report PDF, a selection of stills, maybe a GeoTIFF for the technical recipient. The last step is turning that set into one address your client can open, understand and come back to.

That is the layer DronePortal covers. It does no processing whatsoever — WebODM stays your engine, and nothing about how you process changes. What it does is hold the delivery together:

• The interactive map or 3D view embedded on the page, so panning and zooming work where the client already is
• The quality report, the stills and any downloadable files sitting next to it, not in a separate email
• One access code per project instead of a link per asset
• An address that still resolves next year, when a WeTransfer link is seven days dead

The order matters: steps 1 to 5 are the actual work, and they are the same whether or not you use anything from us. Step 6 is only about how it arrives.

In practice: the actual clicks

1. First, get a public viewer URL. For WebODM that means one of two things. On WebODM Lightning, share the task and copy the public link — that URL is already reachable and goes straight in. On a self-hosted WebODM it does not work (step 5): publish the textured model to an embeddable viewer such as Sketchfab or Polycam instead, and use that link. For the orthophoto you want a tiled map viewer, never the raw GeoTIFF — a 3 GB file is not something an iframe can show.
2. Paste the ordinary page URL; it gets converted on save. A Sketchfab model page, a Matterport /models/ link, a Kuula /post/ link and a Polycam capture page all refuse to be embedded as-is. DronePortal rewrites them to their embed form when you save, so you do not have to hunt for the embed code. One exception: skfb.ly short links are refused with a message — paste the full Sketchfab URL.
3. Dashboard → "+ New project". Pick an existing client or type a name and e-mail straight into the form. Give the project a name and a type, and name the first unit. On save DronePortal creates the client, the project and the unit, generates an 8-character access code, and drops you into that unit's edit screen.
4. Section 🗺 Viewers — one row per viewer. Choose the type (3D Visual, 3D Thermal, 2D Map, 360° Tour), write a label your client will read, and paste the URL. For WebODM: the orthophoto goes under 2D Map, the textured model under 3D Visual. Use "+ Add viewer" for the next one. Underneath, pick the Main viewer — the one that opens first — or leave it on "Automatic (first viewer)".
5. Section 📋 Documents & media — add the report. "+ Add a document or link", set the type to File and use "↑ Upload" for the WebODM quality report PDF (pdf, jpg and png are accepted). Type Link points at something hosted elsewhere. The NL/FR/EN label fields are the button text your client sees, so fill in at least the language of this delivery.
6. Section 📷 Photos — upload the selection. Thermal, visual and zoom images. This is a selection, not a dump: these are the stills that carry your findings, not the full card.
7. Section Portal — open it up. Set the status to Active, choose the language, fill in the capture date and, if the job needs one, an expiry date. The access code sits in this same section.
8. Hand over one link. The client URL is https://{your-subdomain}.droneportal.app/app/portaal/?code={ACCESSCODE}. One address plus one code — no account for your client, nothing to install.

Open that link yourself in a private browser window before you send it. It is the only way to see what your client sees rather than what your logged-in session shows you.

Before you send: a checklist

• Flight date and GSD stated in writing
• EPSG code stated for every georeferenced file
• Every file opens without specialist software — or is explicitly marked as being for the surveyor
• The 3D model's .obj, .mtl and textures travel together
• You opened the delivery on a phone, from outside your own network
• Nothing points at localhost or an internal IP address
• It is clear what is not included, so nobody assumes it is coming
• There is a working route back to you for questions

Five ways a WebODM delivery goes wrong

1. Sending all.zip. Everything, therefore nothing. The client cannot tell what matters.
2. A raw GeoTIFF over WeTransfer. Too big to download comfortably, impossible to open, gone in seven days.
3. A share link to a local instance. Works on your machine only. You will not find out until the client says so.
4. No coordinate system. Makes every georeferenced file in the delivery unverifiable.
5. Six links in three emails. Technically complete, practically lost by the second week.

Same workflow for other tools: delivering a Pix4D project · delivering a DJI Terra reconstruction. Related reading: process locally, deliver professionally and your client never sees your point cloud.

Frequently asked questions

Related reading

• What is a drone client portal?
• Stop sending WeTransfer links to clients

Ready to get started?

Try step 6 on your next WebODM job

Steps 1 to 5 stay exactly as they are. Free trial, no credit card required.