SPZ Format: Technical Guide to Compressed Gaussian Splatting
Updated Mar 2026
SPZ is the compressed Gaussian Splatting format developed by Niantic Labs for their Scaniverse app, first released publicly in September 2024. If you've been struggling with 150–400 MB PLY files for your 3DGS scenes, SPZ is the most practical solution available today — a typical outdoor scan that produces a 200 MB PLY compresses to 18–22 MB SPZ, a 9–11× reduction, with no perceptible quality loss at normal viewing distances. The format achieves this through two complementary techniques: **quantisation** (reducing floating-point precision where the human eye can't detect the difference) and **arithmetic coding** (an entropy-based compression algorithm that exploits statistical redundancy in the quantised data). The result is a binary format that decompresses in under 100 ms on modern hardware, fast enough for real-time web loading. What makes SPZ practically important beyond file size is its trajectory toward standardisation. Niantic open-sourced the reference encoder/decoder (github.com/nianticlabs/spz) and submitted a proposal to the Khronos Group for inclusion in the glTF ecosystem alongside KHR_gaussian_splatting. As of early 2026, the proposal is in active review — SPZ may become part of a ratified glTF extension within 12–18 months, which would make it the de facto interchange format for 3DGS in production workflows. Understanding the binary structure matters if you're building tooling or diagnosing corruption artifacts. This guide explains exactly how SPZ files are laid out, how the compression pipeline works, what quality trade-offs to expect (particularly the spherical harmonics quantisation issue at extreme viewing angles), how to create and convert SPZ files using browser-based tools, and how to evaluate whether SPZ quality is acceptable for your specific use case.
Tools used in this guide
Step-by-Step Guide
- 1
Understand the SPZ File Structure
An SPZ file begins with a 16-byte magic header: the ASCII string `SPST` (4 bytes) followed by a version number (uint32), the total Gaussian count (uint32), and a flags field (uint32) indicating which optional components are present. After the header comes three compressed data streams, each preceded by a 4-byte length field: (1) the **position stream** — quantised XYZ coordinates for every Gaussian, typically 12 bits per axis; (2) the **attributes stream** — opacity, scale (3 values), rotation quaternion (4 values), and base colour (3 values), quantised to 8–12 bits each; (3) the **spherical harmonics stream** — the SH coefficients that give Gaussians their view-dependent colour, quantised aggressively at higher degrees. The entire file is then compressed with zlib-compatible deflate, which is why SPZ files open cleanly with standard decompression tools if you strip the SPST header. Total overhead from the header and length fields is under 40 bytes regardless of Gaussian count.
- 2
How SPZ Compression Works
The compression pipeline has two distinct stages. First, **vector quantisation**: each Gaussian's floating-point attributes are mapped to integers at reduced precision. Position values are quantised relative to the scene bounding box — a Gaussian at absolute coordinate (3.145f, -2.871f, 1.003f) becomes something like (2047, 1102, 3891) in the scene's 12-bit grid. This step alone reduces raw data size by 60–65% compared to 32-bit floats. Critically, positions use 12-bit quantisation while opacity and colour use 8-bit, and spherical harmonics coefficients at degree 3 are quantised to as few as 6 bits. Second, **arithmetic coding via zlib deflate**: the quantised integer streams have strong statistical structure (neighbouring Gaussians tend to have similar positions and colours), and arithmetic coding exploits this to achieve a further 40–50% size reduction. The combination yields the typical 8–12× overall compression ratio relative to raw PLY.
- 3
Identify Quality Trade-offs
SPZ introduces two categories of quality degradation, both intentional. **Position quantisation artifacts** are visible when a Gaussian's true position falls between two grid points — in practice this causes subtle geometric softness at boundaries but is rarely visible at normal viewing distances (more than 0.5 m from the surface in real-world scale). You'll only notice it when doing close-up architectural or product scans where sub-millimetre precision matters. **SH quantisation artifacts** are more problematic: at viewing angles far from the training camera poses (typically >90° from the capture direction), the aggressive quantisation of degree-3 SH coefficients introduces colour banding and saturation clipping. You'll see this as unnatural colour shifts when orbiting around objects captured from one direction. Mitigation: capture your scene from as many angles as possible, and evaluate SPZ quality by orbiting 360° around the scene in polyvia3d's SPZ Viewer before deploying.
- 4
Create SPZ Files from PLY or SPLAT
The fastest no-code path is polyvia3d's browser-based converters. Navigate to /splat-convert/ply-to-spz, drop your PLY file, and the converter runs entirely in your browser — no upload to any server, no file size limit beyond your browser's available memory (typically 2–4 GB on a modern machine). Conversion time for a 200 MB PLY (2M Gaussians) is typically 15–30 seconds on a 2022-class CPU. If you're starting from a SPLAT file, use /splat-convert/splat-to-spz which handles the SPLAT → SPZ pipeline directly. For command-line workflows, Niantic's reference tool `spz-convert` (github.com/nianticlabs/spz) accepts PLY input and produces SPZ output with configurable quantisation levels — use `--sh-degree 1` to reduce SH to degree 1 if you're seeing colour artifacts at extreme angles.
- 5
Verify SPZ Quality Before Deploying
After conversion, open the SPZ file in polyvia3d's SPZ Viewer at /splat-viewer/spz and perform a systematic quality check: (1) Orbit 360° horizontally and check for colour banding, especially on surfaces that were only visible from one side during capture. (2) Zoom to within 10 cm of surfaces in scene scale and check for geometric softness or stepped artifacts. (3) Check opacity — thin structures like wires, grass, or hair occasionally show opacity quantisation as intermittent disappearing. If any artifact is unacceptable, convert back to SPLAT format (4–6× compression, better quality) or keep PLY. You can convert back with polyvia3d's /splat-convert/spz-to-ply if you need to return to raw float format for further processing.
- 6
Understand SPZ's Standardisation Status
Niantic published the SPZ specification and reference implementation under Apache 2.0 in September 2024 (github.com/nianticlabs/spz). Since then, support has been added to gsplat.js, antimatter15/splat viewer, and polyvia3d. The Khronos Group proposal for KHR_gaussian_splatting includes SPZ as a compression option alongside a new KSplat-inspired format. As of March 2026, the Khronos proposal is in public review phase — implementation in production glTF tools like Blender's glTF exporter and Babylon.js is expected to follow ratification. For production workflows today, SPZ is safe to use as a distribution format if you control the viewer, since all major web and desktop viewers support it. For archival or interchange with unknown pipelines, PLY remains the most universally supported format.