Gaussian Splat Formats: PLY, SOG, SPZ, KSplat

Gaussian Splatting produces astonishing visuals. It also produces file format chaos.

The original Inria research used .ply — a 30-year-old format never designed for splats — as a convenient container. Since then, a handful of teams have shipped purpose-built splat formats with very different goals: smaller files, faster streaming, lossy vs lossless compression, viewer-specific layouts.

Here is what each format actually is, what it’s good at, and when you should reach for it.

Why PLY was never going to be enough

The Polygon File Format was designed at Stanford in 1994 to store triangle meshes. It’s an extensible container — you can stuff arbitrary per-vertex attributes into it — and that’s why the original 3D Gaussian Splatting paper used it. Every Gaussian becomes a “vertex,” and the spherical harmonic coefficients, scale, rotation, and opacity become per-vertex attributes.

It works, but the format has three problems for splat delivery:

1. No compression. PLY stores raw float32 values. For a scene with 4 million Gaussians and 48 SH coefficients each, that’s around 1.4 GB before you’ve encoded any positions.
2. No streaming. PLY is monolithic. You can’t start rendering until the whole file is loaded.
3. No spatial ordering. Gaussians are stored in training order, which is essentially random. You can’t progressively load nearby splats first.

For an archive format these are non-problems. For a delivery format they are dealbreakers. So purpose-built formats appeared.

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

The format roster

There are five formats you’re likely to encounter in 2026:

The numbers above are typical for a 4-million-Gaussian indoor scene captured with consumer drone or phone video. Outdoor scenes with more Gaussians scale roughly linearly.

PLY (raw)

The format you’ll get out of the Inria reference implementation, Brush, gsplat, and most academic splat trainers. Each Gaussian is stored as a PLY vertex with these attributes:

• x, y, z — position (3 floats)
• nx, ny, nz — normal (unused for splats, but PLY-required, 3 floats)
• f_dc_0..2 — diffuse colour SH coefficients (3 floats)
• f_rest_0..44 — higher-order SH coefficients (45 floats for SH degree 3)
• opacity — single float, pre-sigmoid
• scale_0, scale_1, scale_2 — three log-scales
• rot_0..3 — quaternion rotation (4 floats)

That’s 62 floats per Gaussian, or 248 bytes. Multiply by a few million Gaussians and you’re at 1–3 GB for a typical scene. Larger scenes — outdoor sites, full building captures — can hit 5 GB or more.

Pros: Lossless. Universally readable. The de facto archive format. Every research project and most production trainers output it.

Cons: Huge. No streaming. Slow to parse.

Use it for: archive, re-training, format conversion, anything where you cannot afford to lose precision.

SuperSplat compressed PLY

PlayCanvas’s SuperSplat editor introduced a compressed PLY variant — same file extension, same overall structure, but with Gaussians sorted into a Morton-order spatial layout and per-attribute quantisation. The file is still a valid PLY, just substantially smaller.

The recipe:

• Sort Gaussians by Morton (Z-order) curve for spatial locality
• Quantise positions to 16-bit normalised values
• Quantise SH coefficients to 8-bit
• Quantise rotation quaternions to 10-bit-per-component
• Reorder attributes into chunked layouts that compress well

Output sizes land at 200–400 MB for typical scenes, with a quality loss most viewers will not detect.

Pros: Still a .ply, so existing PLY tooling can at least open it. Significant size reduction. Good viewer support (SuperSplat, Spark, many others now read it).

Cons: Not universally supported. Some older viewers expect raw float32 PLYs and won’t read the packed variant. Quantisation is lossy, though mildly.

Use it for: delivery to clients via SuperSplat-compatible viewers, marketing splats, anything where you want PLY compatibility but smaller files.

SOG — Self-Organizing Gaussians

Self-Organizing Gaussians is a 2024 research paper from Fraunhofer HHI. The core idea: arrange the Gaussians into a 2D grid where nearby grid positions correspond to spatially nearby splats, then store the grid as a set of textures. Standard image compression (JPEG XL, PNG) then compresses the textures aggressively.

The output .sog file is a packaged bundle of textures plus a small header. Sizes typically land at 80–200 MB for scenes that would be 1.5 GB as raw PLY.

Pros: Smallest of the major formats. Lossless or near-lossless depending on the texture codec used. Spatially structured, so partial loading is theoretically possible.

Cons: Newer, with thinner viewer support. Currently best supported in the original research viewer and a few derivatives. Encoding is slower than the alternatives.

Use it for: archive-quality storage at delivery sizes. If your viewer supports it, this is one of the most efficient formats available.

KSplat

KSplat is the format developed by Mark Kellogg for the GaussianSplats3D WebGL viewer. It’s a custom binary format with three compression levels (0, 1, 2) trading file size against quality.

Compression levels:

• Level 0 — full precision, similar size to raw PLY
• Level 1 — half-precision floats and quantised SH, ~3× smaller than raw
• Level 2 — aggressive quantisation, ~7× smaller than raw

The format is designed for fast streaming and progressive loading in the GaussianSplats3D viewer.

Pros: Designed specifically for browser playback. Streams progressively. Fast parsing. Good quality at level 1.

Cons: Tied to the GaussianSplats3D viewer ecosystem — not universally supported. Lossy at higher compression levels.

Use it for: delivery via GaussianSplats3D or any viewer that consumes the KSplat format. A reasonable default for web embeds.

SPZ

SPZ is Niantic’s format, released in late 2024. Aggressive quantisation: positions to 24 bits, SH coefficients to 8 bits, rotations to a compact normalised quaternion. The result is the smallest commonly-deployed splat format, typically 10× smaller than the equivalent raw PLY.

The format is open-source, well-documented, and increasingly supported across viewers. Conversion tools exist for .ply → .spz in most splat toolchains.

Pros: Smallest commonly-supported delivery format. Open spec. Wide and growing viewer support (Spark, Niantic’s own viewers, many others). Fast to load.

Cons: Lossy. Quality loss is visible in side-by-side comparison with raw PLY, though usually not in isolation. Not suitable as an archive format — once you’ve converted to SPZ, you’ve lost precision you can’t recover.

Use it for: client delivery, web embeds, mobile-targeted splats, anything where bandwidth matters more than reproducible precision.

How they compare

The same scene exported to each format, rough numbers for a typical 4M-Gaussian indoor capture:

Load time assumes a 50 Mbps connection with no compression on the transport layer. In practice, gzip or brotli on the host shaves another 10–20% off the wire bytes for some formats — though aggressively pre-compressed formats like SPZ don’t gain much.

Viewer support reality check

Format support varies by viewer. As of mid-2026, the state of play:

The pragmatic conclusion: if you’re delivering to a fixed viewer (your own embed or a platform like Swyvl), pick the format that viewer prefers. If you’re delivering raw files for the client to view in their own tool, SPZ is the broadest delivery format and PLY is the safest archive format.

Which format should you use?

A pragmatic decision tree:

For your archive: raw .ply. Always. You’ll thank yourself in three years when a better delivery format appears and you want to re-export.

For client delivery via your own platform: whichever format your viewer prefers. Swyvl, for instance, handles .ply, packed .ply, .ksplat, and .spz. Pick the smallest format your viewer supports without quality regressions.

For client delivery via download: .spz. Smallest, widest support, the format the client is most likely to find a viewer for if they want to look at it in their own tooling.

For web embeds and marketing: .spz. Smallest payload, fastest first paint, broadest viewer support.

For research, reprocessing, or further training: raw .ply. Anything else has lost information you might need.

Where this is heading

Splat formats are still in the “VHS vs Betamax” phase. SPZ and SOG are gaining ground. KSplat is dominant in the GaussianSplats3D-derived viewer ecosystem. SuperSplat’s packed PLY has the advantage of being a valid PLY, which helps interoperability.

Expect consolidation over the next 18 months. SPZ is the current betting favourite for a default delivery format — open spec, Niantic backing, aggressive compression, broad uptake — but the space moves fast.

Until the dust settles, the safe play is the one professionals have used for decades with every other format war: archive in the lossless format, deliver in whatever your client’s viewer reads, and keep your conversion pipeline scripted so you can re-export when the landscape changes.

For more on splats themselves and what they’re useful for, see Gaussian Splats: The Next-Gen 3D Reconstruction and How to Share Gaussian Splats with Clients.