What Is a .SPLAT File? The Lightweight Gaussian Splatting Format Explained

The .splat format was born in September 2023 when Kevin Kwok (known as antimatter15) announced the first WebGL-based 3DGS Viewer on X. To let others easily share and load scenes, he designed .splat as the companion file format.

SPLAT's design philosophy is minimalism: rather than compressing PLY, it retains only the minimum data needed for rendering — stripping out view-dependent spherical harmonics (SH) coefficients entirely. This trade-off makes SPLAT about 50% smaller than PLY, but view-dependent color effects (highlights that shift as you orbit the scene) are lost.

As of early 2026, SPLAT remains the most widely supported web 3DGS format — virtually every web-based 3DGS viewer supports it, making it the go-to choice for universal compatibility.

Kevin Kwok's antimatter15 WebGL Viewer quickly gained 2700+ stars on GitHub after its September 2023 release, becoming a foundational open-source project in the Web 3DGS ecosystem. Much like how JPEG became the web standard for images not by being first but by being most widely adopted, .splat became "the first 3DGS format to achieve mass web distribution."

Each Gaussian in SPLAT is stored in exactly 32 bytes with a fixed layout and no compression: bytes 0-11 store the position (x, y, z) as 3 float32 values; bytes 12-23 store the anisotropic scale (scale_x, scale_y, scale_z) as 3 float32 values; bytes 24-27 store RGBA color (derived from SH DC component) as 4 uint8 values including transparency; and bytes 28-31 store the rotation quaternion as 4 uint8 values (normalized).

Key technical trade-offs define SPLAT's character: there is no file header — the receiver infers Gaussian count by checking if the file size is divisible by 32. There is no formal specification — SPLAT is a convention, with each tool independently implementing the 32-byte layout. Colors are the zero-order SH component (DC term) converted to RGB values, permanently discarding higher-order SH. Because higher-order SH is removed, SPLAT files cannot distinguish different lighting conditions of the same scene — the color is "the color seen from one fixed angle."

SPLAT occupies a unique position in the 3DGS format landscape. At about 50% of PLY size, it is a moderate compression — much less aggressive than SPZ (10% of PLY) or KSPLAT (35% of PLY). Its complete lack of spherical harmonics is the main quality trade-off, but this is offset by having the broadest web viewer support of any 3DGS format.

For new projects where SPZ is supported, SPZ is generally the better choice: smaller files and preserved SH. SPLAT's role is shifting from "the web standard" to "the maximum compatibility fallback" — the format you use when you need to reach the broadest possible existing viewer support.

Sharing with audiences using older viewers: If your 3DGS scene needs to reach people using various web viewers (social media sharing, email attachments, client demos), SPLAT's universal compatibility is its greatest strength. The vast majority of web 3DGS viewers built in 2023-2024 support SPLAT first.

Embedding in third-party platforms: Many 3DGS showcase platforms use SPLAT as their upload format. If you need to upload to such platforms, converting PLY to SPLAT is a necessary step.

Static displays without view-dependent lighting: Product model rotations, portrait scans, museum artifact displays — these scenarios typically don't need view-dependent highlight effects. SPLAT's fixed colors are perfectly adequate, with 50% smaller files than PLY.

When NOT to use SPLAT: Indoor scenes (strong view-dependent lighting effects become noticeably flat without SH). Archival purposes (use PLY or SPZ instead — SPLAT's SH loss is irreversible). Three.js production apps (use KSPLAT or SPZ for better performance).

To ground the format comparison in concrete numbers, consider a standardized test scene: a room-scale 3DGS capture containing 1,000,000 Gaussians trained with degree-2 spherical harmonics. SPLAT's fixed 32-byte-per-Gaussian layout produces a perfectly predictable file: exactly 32 MB (32 × 1,000,000 bytes). No headers, no metadata overhead, no variability — the file size is always exactly 32 × Gaussian count.

Cross-format file size comparison for this 1M Gaussian scene: PLY (full float32 with SH) = 236 MB (baseline). SPLAT = 32 MB (14% of PLY). SPZ (full SH, gzip compressed) = 24 MB (10% of PLY). KSPLAT compression level 2, no SH = 72 MB (31% of PLY). SPLAT is the second-smallest format after SPZ, but unlike SPZ, SPLAT sacrifices all spherical harmonics data to achieve this size.

Loading time comparison on a 100 Mbps connection reveals SPLAT's unique trade-off profile: SPLAT downloads in approximately 2.6 seconds and renders immediately — there is zero decode overhead because the 32-byte layout maps directly to GPU-ready data via a typed ArrayBuffer view. SPZ downloads faster (2.0 seconds for 24 MB) but requires a gzip decompression step adding 200-400ms. KSPLAT shows first pixels in 0.5-1.2 seconds via progressive loading despite a larger total file. PLY requires 19+ seconds for the full 236 MB download.

SPLAT's hidden advantage is decode simplicity. The entire "parser" is essentially one line of code: create a Float32Array and Uint8Array view over the downloaded ArrayBuffer. No header parsing, no field extraction, no decompression. This makes SPLAT the most predictable format for performance budgeting — you know exactly how large the file will be and exactly how long decoding takes (effectively zero). For applications where predictability matters more than absolute minimum size, this is a genuine engineering advantage.

CDN configuration for SPLAT files: Set Content-Type to application/octet-stream (the standard for binary downloads). Enable gzip or brotli transfer compression on your CDN — SPLAT's binary data contains repetitive byte patterns (adjacent Gaussians often share similar position and color values), allowing 15-25% reduction with gzip and 20-30% with brotli. A 32 MB SPLAT file typically transfers as 24-27 MB with gzip enabled. This is free bandwidth savings with zero client-side cost. Cloudflare Pages, Vercel, and Netlify all enable this by default for binary assets.

Multi-format fallback strategy for maximum compatibility: The recommended production pattern is to generate both SPZ and SPLAT versions of each scene, then implement client-side format negotiation. First, attempt to load the SPZ version (smaller, better quality). If the SPZ decoder fails or the viewer does not support SPZ, fall back to SPLAT. This pattern ensures you serve the best available format while maintaining universal compatibility. Store both versions on your CDN — the storage cost is negligible compared to the UX benefit.

Mobile optimization guidelines: Mobile browsers with integrated GPUs typically handle 500,000-1,000,000 Gaussians (16-32 MB SPLAT) comfortably. Beyond 1M Gaussians, expect WebGL memory allocation failures on most mobile devices. For scenes exceeding this limit, pre-process the PLY to reduce Gaussian count (using decimation or importance-based culling) before converting to SPLAT. Alternatively, split large scenes into spatial regions and load SPLAT files on demand as the user navigates.

Preloading strategy for critical scenes: Use <link rel="prefetch" href="/scenes/hero.splat"> in your HTML head to begin downloading the SPLAT file before the user navigates to the 3D view. For single-page applications, trigger the fetch programmatically when the user shows intent (hovering over a "View in 3D" button, scrolling toward the 3D section). SPLAT's predictable file size makes bandwidth budgeting straightforward — you know exactly how many bytes the prefetch will consume.

SPLAT holds a unique position in 3DGS history as the first format to achieve mass web distribution. Kevin Kwok's antimatter15 viewer was the catalyst that transformed Gaussian Splatting from a research technique into a web technology. The .splat format was not designed by committee or standardized by a consortium — it emerged organically from one developer's pragmatic decision to strip a PLY file down to its rendering essentials. This origin story explains both SPLAT's strengths (extreme simplicity, zero dependencies) and its limitations (no formal spec, no extensibility).

The 2026 ecosystem status: SPLAT remains the most widely supported web 3DGS format by viewer count. Every major web-based 3DGS viewer supports SPLAT — antimatter15's original viewer, Luma AI's viewer, PlayCanvas, gsplat.js, and dozens of community projects. However, new viewer development increasingly targets SPZ as the primary format, with SPLAT as a compatibility fallback. The trend is clear: SPZ is the future standard, SPLAT is the compatibility layer.

Relationship with Khronos glTF 3DGS extension: The Khronos Group's ongoing work to add Gaussian Splatting support to the glTF standard is based on SPZ's design principles (compressed, full SH, standardized). SPLAT is not part of this standardization effort and is unlikely to be — its lack of SH support and absence of a formal specification make it unsuitable for a standards-track format. When the glTF 3DGS extension is finalized (expected late 2026 or 2027), it will further accelerate the shift from SPLAT to standardized formats.

Long-term outlook: SPLAT will not disappear — the installed base of viewers and tools supporting it is too large for a sudden obsolescence. Instead, SPLAT will gradually transition from "the web 3DGS format" to "the universal compatibility fallback." New projects should default to SPZ for web delivery and PLY for archival, using SPLAT only when targeting viewers that do not yet support SPZ. Polyvia3D will continue to support SPLAT viewing and conversion indefinitely, regardless of the format's evolving role in the ecosystem.