Sorting Out 3DGS File Formats

01 Quick reference: start with the big picture

Start with this table to get a feel for all eight formats. Each has its own section below, and the byte-level technical details are tucked into a collapsible "Inside the spec" block in each section.

02 PLY (original, uncompressed)

This is the de facto common language of 3DGS — the format the original Inria paper outputs directly. Each Gaussian records position (x, y, z), scale, rotation (quaternion), opacity, and color. Color is stored as spherical harmonics (SH) coefficients, and using degree 3 requires 45 coefficients per Gaussian (3 channels × 15) — which makes PLY the largest file size of any format here.

In the wild ── This is the exact output of the official Inria implementation, and the exports from Polycam, Luma AI, and XGRIDS LCC Studio follow the same layout. SuperSplat reads and writes it directly, which makes PLY the hub for editing too.

03 SPLAT (antimatter15)

A simple fixed-length binary format created for splat (antimatter15), one of the earliest web viewers. Each Gaussian is a fixed 32 bytes (position, scale, color, covariance) and carries no SH coefficients for view-dependent color, so files end up roughly half the size of PLY.

04 KSPLAT (mkkellogg/GaussianSplats3D)

A compression format built specifically for the Three.js library GaussianSplats3D. Data is split into chunks and designed for progressive streaming, rendering each chunk as it arrives — even a scene over 100MB can show its first frame in 0.5-1 seconds. You can choose the compression level, including a setting that compresses SH coefficients down to 8 bits.

05 SPZ (Niantic Spatial)

A compression format developed by Niantic Spatial (Scaniverse) that's becoming something of an industry standard. It was also adopted as the compression method for glTF's KHR_gaussian_splatting compression extension (09). v1 through v3 used gzip compression; the latest v4 switched to zstd compression plus a plain 32-byte header. The v4 header starts with the magic bytes "NGSP" and exposes the Gaussian count, SH degree, version, and more as directly readable text, so you can peek at the point count just by reading the header — no need to decode the whole file.

In the wild ── Scaniverse exports SPZ, and Niantic open-sourced it under MIT (nianticlabs/spz). The stated compression is roughly 1/10 the size of the equivalent PLY.

06 SOG (PlayCanvas)

Developed by PlayCanvas and sometimes described as "WebP for Gaussian Splatting." Gaussians are sorted by attributes such as position, scale, and color, then each attribute is compressed as a WebP image and linked together via meta.json. Because similar Gaussians end up adjacent before image compression is applied, the compression is highly efficient — there are reports of a 1GB PLY shrinking to around 55MB (roughly 20x).

07 RAD (Spark)

A streaming-only format that Spark, the Three.js renderer, added in 2.0, capable of storing an LOD tree as-is. You build and save the LOD tree ahead of time with the build-lod command, and at viewing time only the chunks (.radc) you need are fetched via HTTP Range Requests. It's a "coarse-to-fine" design: a rough version appears instantly, and more detail streams in as the viewpoint moves. Locahun 3D's own viewer builds its custom parallel decoding and LOD control around this RAD format as well.

In the wild ── Our own viewer streams a 934MB, 49.4-million-gaussian RAD to first render in about 6 seconds (after that, camera moves hit the resident cache with no wait). The only primary sources for the format are Spark's documentation and source code — there is no standalone spec document like SPZ's or SOG's yet.

08 LCC / LCC2 (XGRIDS)

A container format developed by XGRIDS for handling city-scale scenes with LOD (level of detail). Rather than a single file, it's made up of JSON metadata (an octree-style LOD tree) and a data/3dgs/ folder holding the actual data. The underlying data is stored as either SOG or SPZ, and adjacent nodes are merged into a single file. PortalCam scans also include this: LCC Studio's export contains a Lcc2/lcc2-result/ folder (3dgs as SOG, mesh as PLY).

09 glTF (KHR_gaussian_splatting)

The official Khronos extension, currently being standardized, for storing 3DGS inside glTF/GLB. A release candidate (RC) was published in February 2026 and it's now in the final stages toward formal ratification. Compression uses the SPZ-based extension donated by Niantic Spatial (KHR_gaussian_splatting_compression_spz). Its biggest significance is the shift away from a proliferation of proprietary formats toward building on top of glTF, a general-purpose 3D standard. Cesium adopted it as a payload to support hierarchical LOD streaming in 3D Tiles (April 2026), making it possible to deliver city-scale 3DGS with geographic coordinates. Conversion CLIs like gsbox also support PLY⇄GLB.

10 So which one should you use?

One core principle first. Compressed formats like SPZ, SOG, and KSPLAT quantize the data, and once compressed, the original quality cannot be recovered. Whatever you pick for delivery, keep the PLY straight out of training as your master and derive per-use-case copies from it. Format selection is not about choosing a master — it's about choosing how you deliver and hand off.

With that in place, here's a rough guide by use case. Use it together with our comparison of 3DGS-capable software and tools to decide which format to use with which software.

• Passing data to another DCC (Houdini, Blender, etc.) ── PLY. More tools now read SPZ directly (3ds Max 2027.2, for one), but PLY is still the only format every tool is guaranteed to open
• Publishing and sharing on the web ── Decide by what your viewer supports. If you're displaying through the PlayCanvas family (SuperSplat, Spark), go SOG for maximum compression (note it's a folder, not a single file). If you need one file to hand around, or you can't predict the recipient's setup, SPZ is the safe pick
• Switching LOD in a city-scale scene ── LCC2 if you're on XGRIDS' SDKs (UE5/Unity); Cesium's 3D Tiles + glTF (09) if you want an open standard with geospatial coordinates. Remember to check LCC2's proprietary license
• Streaming an ultra-large scene with over 100 million points ── RAD. Spark-only, but it's currently the only format that delivers the whole LOD tree over HTTP Range requests
• Building a custom viewer with GaussianSplats3D ── KSPLAT. Gets the benefit of progressive display
• Long-term storage and distribution on a standard ── glTF (KHR_gaussian_splatting) is where this is heading, but it's still at the RC stage. For archival today, the reliable setup is a PLY master plus compressed derivatives

As for SPLAT: there's little reason to adopt it for new work. It has no formal spec and drops the SH coefficients — even for "just want a quick look" cases, tossing the PLY straight into a viewer like SuperSplat is faster and safer.

Converting between formats is mostly covered in one place by splat-transform.