PLY, SPZ, and .splat: the extension is not the schema

How three common Gaussian splat containers differ, and why reliable compatibility checks need to inspect the actual file layout.

Direct answer. Treat PLY, SPZ, and .splat as different container families—not compatibility guarantees. A reliable viewer verifies each file's header, version, record layout, and decoded resource plan before rendering.

Comparison diagram showing PLY, SPZ, and splat filenames flowing through header, version, schema, record-layout, and resource validation
Format validation map A container name narrows the first parser choice; compatibility still depends on the content found inside. This is an explanatory diagram, not a compatibility guarantee.

How Boreal Splat helps

Boreal Splat is designed to report what it detected—not simply repeat the extension

The intended Inspector separates a recognized schema, an unsupported variant, and malformed data. That distinction gives the user a concrete next step without implying that every file with a familiar suffix is supported.

Captured from Boreal Splat running on an iPhone simulator. Sample files are used only to demonstrate the current interface.

Boreal Splat Inspector showing a PLY file name, size, detected format, binary little endian version, and Gaussian count
InspectorA current app screen reporting detected content independently of the filename suffix.

Gaussian splat workflows use several file families, and each name hides important variation. A viewer that recognizes an extension has only completed the first step.

PLY is a container, not a 3DGS guarantee

PLY can represent ordinary point clouds and many custom property layouts. Gaussian splat exporters commonly add position, opacity, scale, rotation, and spherical-harmonic properties, but the exact names and data types can vary by tool.

Reliable detection checks the header and required property relationships. It should not label every PLY file as a Gaussian splat.

SPZ is compressed and versioned

SPZ packages Gaussian splat data compactly, which can make transfer and storage easier. Compatibility still depends on the version, structural validity, and the decoder’s supported feature set. The file’s compressed size does not directly reveal its peak decoded memory use.

.splat describes a common packed layout

Files ending in .splat often use a compact record layout intended for fast viewing. The label is not a universal standard for every producer. Record length, field order, and file-size divisibility should be validated before decoding the full payload.

What a useful viewer should report

For any of these formats, the diagnostic surface should distinguish:

  • the detected content from the filename extension;
  • a recognized and supported schema from an unknown layout;
  • malformed or truncated data from a merely unsupported variant;
  • on-disk size from estimated decoded resource needs.

That distinction makes the result actionable: the user can retry with a safe display plan, return to the exporter with concrete information, or convert a supported source without guessing.

Primary format references

  • Niantic Labs SPZ repository describes SPZ as a compressed format for 3D Gaussian splats and provides the reference implementation.
  • The Stanford PLY specification describes PLY’s flexible header, elements, and properties.
  • The .splat suffix is used by several packed-viewer workflows; because there is no single universal producer contract, record length and field order must be validated rather than inferred from the suffix.

Use the safe opening sequence

Inspect the file before committing to a full decode.

Follow the preflight checklist for schema, resource-risk, and source-preservation decisions.

Use the preflight checklist