How to Share Gaussian Splats with Clients

You’ve trained a Gaussian splat of a site. The scene looks incredible in your local viewer. Now you need to get it in front of a client who has never heard of Gaussian Splatting and isn’t going to install a desktop application to look at it.

This is harder than it sounds. A raw .ply splat is typically 1–5 GB. The format isn’t recognised by Dropbox, Google Drive, or anything else with a built-in preview. The client double-clicks the file and gets nothing useful.

Here are your actual options, ordered from worst to best.

The size problem first

Before we get to delivery, a quick reality check on file sizes.

For a deeper look at the formats themselves, see Gaussian Splat Formats: PLY, SOG, SPZ, KSplat.

The format you choose drives every downstream decision. A 4 GB raw PLY is fine for archive. It’s a terrible thing to email a client. A 200 MB .spz streams in a browser in under a minute on a normal connection.

For the rest of this guide, assume you have a compressed delivery file (.spz or .ksplat) sitting next to your raw .ply archive.

Want to try it now? Open a Gaussian splat in the browser — free, no signup, your file stays on your computer.

Option 1: Drop the file in WeTransfer or Dropbox

The path of least resistance: zip the splat, upload to WeTransfer, send the link.

What goes right: the file gets to the client.

What goes wrong: the client downloads the file and then can’t open it. There is no native viewer for splats on Windows or macOS. They email you back asking what to do. You spend the next two days explaining how to install SuperSplat, or pointing them at a third-party WebGL viewer URL and hoping it loads.

You will also burn through WeTransfer’s size limit fast. A 3 GB raw splat exceeds the free tier. Even compressed splats stack up if you’re delivering multiple capture sessions per project.

When it works: when the client is another splat-literate technician who knows what to do with a .ply. Almost never the case in practice.

Option 2: Host your own WebGL viewer

The DIY route. Take an open-source splat renderer — there are several mature ones, including Mark Kellogg’s GaussianSplats3D, SuperSplat viewer, and Spark — and host it yourself.

The recipe:

1. Convert your splat to the format your viewer expects (typically .ksplat or .spz)
2. Upload the splat file to a static host (S3, Cloudflare R2, Netlify)
3. Configure the viewer HTML to point at the splat URL
4. Send the URL to your client

Pros: Free. Real interactive viewing in a browser. The client installs nothing.

Cons: You’re now running a small web hosting operation. You need somewhere to put the files, a way to keep them organised across projects, a way to control who can view them, and a way to take them down when the project ends. None of this is hard if you’ve done it before. All of it is hours of work the first time. None of it is what you were hired to do.

You also lose any branding. The viewer is whatever the open-source project shipped. Your client sees a generic WebGL canvas, not your work.

When it works: technically capable teams with an IT person, a one-off marquee project where the bespoke effort is worth it, or as the underlying infrastructure for a larger internal tool.

Option 3: Generic 3D model hosts

Sketchfab, Modelviewer.dev, and similar platforms host 3D models in a browser. Some have added experimental splat support. As of mid-2026, support is patchy — file size limits are usually too low for production splats, and the import pipeline often reduces quality.

These platforms are built for game-ready, mesh-based 3D models. Splats are a different beast. Expect format mismatches, watermarks on free tiers, and no real workflow for survey or drone deliverables.

When it works: small marketing-grade splats where you don’t mind the platform’s branding and limits. Not for client delivery on real projects.

Option 4: A spatial delivery platform with a built-in splat viewer

Platforms like Swyvl handle splat delivery as a first-class workflow. You upload your .ply, .spz, .ksplat, or compressed PLY, the platform serves it through a sandboxed browser viewer, and you share a single link.

The client clicks the link, sees your branding, and navigates the splat with mouse and keyboard. They install nothing. You see when they opened it and what they looked at.

This is the workflow we built Swyvl for surveyors and drone operators around. The splat sits inside a session, alongside the rest of your deliverables — orthos, point clouds, reports — so the client gets a single coherent portal rather than a pile of disconnected links.

Pros: No hosting. Branded delivery. Activity tracking. Splats live alongside other survey deliverables in one place. Permanent links.

Cons: Subscription cost.

When it works: any time you’re delivering splats to clients on more than an ad-hoc basis.

Format choice: archive vs delivery

A practical rule that holds up across most workflows:

Don’t deliver raw PLY unless your client has explicitly asked for the archive file and knows what to do with it. The quality difference between a raw PLY and a well-compressed .spz is not visible in a typical client review. The download time difference is enormous.

A worked example: drone operator delivering a wedding venue

This came up in conversation with a drone operator last month, so it’s worth walking through.

The brief: capture a heritage estate that’s used as a wedding venue, give the event planner a way to show prospective couples around the grounds remotely. The planner is not technical. The couples definitely aren’t.

The capture: roughly 40 minutes of overlapping drone video at 4K, walked-around handheld coverage of the main building entrance and ceremony locations, total around 12 GB of source video.

The processing: COLMAP for camera pose estimation, 3DGS training on a cloud GPU instance, output as a 2.3 GB raw .ply.

The compression: convert the .ply to .spz using one of the open-source converters. Output: 280 MB. Visual quality difference: imperceptible at typical viewing distances.

The delivery: upload the .spz into a Swyvl site for “Hartfield Estate,” organise into a “May 2026 Capture” session alongside the 4K showcase video and a one-page PDF brief. Set the share link to require an email address for access. Send the link to the event planner.

The result: the planner sends prospective couples a single branded link. They open it on a laptop or desktop, navigate the estate grounds in their browser, and the planner gets a notification each time the link is opened. No installs, no downloads, no support tickets.

Total elapsed time from “splat is processed” to “link is in client’s inbox”: about ten minutes.

What about mobile?

Splat rendering is GPU-intensive. A 300 MB .spz of a complex scene will play reasonably on a modern iPhone or high-end Android, but choke a five-year-old budget device. If your client base is mobile-heavy, test on a representative device before promising mobile viewing.

For mission-critical mobile delivery, consider providing a fallback — a 4K orbit video render of the splat alongside the interactive version. Older phones still get a high-quality experience. Newer phones and laptops get the full interactive splat.

What about offline viewing?

Some clients want a copy of the splat for their archive. Two ways to handle this:

1. Deliver the compressed splat as a download alongside the viewer link. They get the file. They can use it later if a tool catches up to support it natively.
2. Provide a single-file HTML viewer. Bundle the splat with a self-contained HTML viewer page. Double-click the HTML, the splat opens in a browser. This works offline forever, with no platform dependency.

Both approaches are reasonable. The single-file HTML viewer is the more future-proof option if you suspect the client will lose the link.

Permissions and access control

Splats are visually striking and often capture sensitive locations — private homes, secure industrial sites, heritage sites with restricted access agreements. Treat splat delivery with the same access discipline as point clouds.

At minimum, your delivery method should support:

• Email-gated access (the recipient enters their email before viewing)
• Optional password protection on the link
• The ability to revoke access when the project closes
• An audit trail of who viewed what and when

If you’re using WeTransfer or a public Dropbox link, you have none of these. If you’re using a delivery platform, you should have all of them by default.

The simple answer

If you’re delivering one splat to one technical recipient, send the .spz file directly and tell them which viewer to use.

If you’re delivering splats to clients on a regular basis — to non-technical recipients who need to actually look at the work — use a delivery platform with a built-in splat viewer. The combination of compressed file format, browser viewer, branded portal, and audit trail is what turns “I sent you a 3 GB file” into “your client just toured your capture in their browser.”

The splat itself is impressive. The delivery should be too.

FAQ: Can clients measure things in a splat viewer?

Not reliably. Gaussian splats are not metric — the geometric fidelity varies across the scene and the file isn’t tied to real-world coordinates. If your client needs measurements, deliver the corresponding point cloud or photogrammetry mesh alongside the splat. See Gaussian Splats: The Next-Gen 3D Reconstruction for the full picture on what splats can and can’t do.

FAQ: Do splats work in VR headsets?

Yes, with the right viewer. Several open-source splat renderers support WebXR. Quest 3 and Vision Pro both render splats well at native resolution. This is increasingly the preferred way to review architectural and heritage captures.