PLY File Documentation

---

Technical details

Feature	Value
Full name	Polygon File Format (Stanford Triangle Format)
File extension	.ply
MIME type	model/ply
Format type	3D geometry — vertex and face lists
Developer	Stanford University (Greg Turk)
Introduced	Early–mid 1990s
Encodings	ASCII text; binary little-endian; binary big-endian
Header	Always ASCII text, even in binary files
Magic word	ply on line 1, then a format line
Header terminator	end_header
Core elements	vertex (x, y, z) and face (vertex index list)
Optional per-vertex data	Colour (r,g,b), normals (nx,ny,nz), texture coords, confidence
Extensibility	Arbitrary custom elements and properties
Open standard	Yes — publicly documented, no licence
Typical sources	3D scanners, photogrammetry, LiDAR/depth sensors
Free viewers/editors	MeshLab, Blender, CloudCompare
Common exports	.stl, .obj, .glb, .fbx, .xyz
Related extensions	.obj, .stl, .glb, .gltf, .fbx, .pcd, .xyz
Specification	paulbourke.net/dataformats/ply/

What is a PLY file?

A .ply file stores a 3D object in the Polygon File Format, also called the Stanford Triangle Format. It was created at Stanford University in the early-to-mid 1990s (Greg Turk is credited with the design) to store the 3D data captured by laser scanners, most famously the models of the Stanford 3D Scanning Repository such as the Stanford Bunny. The format describes an object as a set of elements, primarily a list of vertices (3D points) and a list of faces (polygons, usually triangles, referencing those vertices).

PLY's defining trait is extensibility. Beyond position, each vertex or face can carry arbitrary extra properties: RGB colour, surface normals, transparency, texture coordinates, or a scanner confidence value. That flexibility is why PLY became the de-facto format for 3D scanning, photogrammetry and point clouds, where the raw output is a dense cloud of coloured points rather than a clean manufactured mesh. Unlike OBJ, which pushes materials into a separate .mtl file, PLY keeps geometry and per-vertex colour together in one self-contained file.

Two encodings, one text header

PLY comes in three encodings, declared on the second line of every file: ascii, binary_little_endian and binary_big_endian. The ASCII form writes each vertex and face as human-readable numbers, one per line: easy to inspect and edit, but large and slower to parse. The binary forms pack the same values as raw bytes in the stated byte order, producing files several times smaller that load far faster, which matters when a scan holds tens of millions of points.

Crucially, the header is always ASCII, even in a binary file. So the beginning of any PLY, regardless of encoding, is readable text that tells you exactly what the file contains before a single data byte is parsed. That is a deliberate design choice: a reader parses the text header, learns the element counts and property layout, then switches to the declared encoding for the body.

The header: magic word, format and end_header

The header opens with the magic word ply on its own line, then the format line, then any number of comment lines, then the element and property declarations, and finally the line end_header. Nothing before end_header is data; everything after it is.

ply
format ascii 1.0
comment created by a 3D scanner
element vertex 8
property float x
property float y
property float z
property uchar red
property uchar green
property uchar blue
element face 6
property list uchar int vertex_index
end_header

This header declares two elements. There are 8 vertex records, each with six properties: three float coordinates and three uchar (0–255) colour channels. There are 6 face records, each a single list property. A reader now knows the precise byte or line layout of every record that follows, and can allocate and parse the body without guessing.

Elements, scalar properties and list properties

An element is a named record type with a count (element vertex 8 means “8 vertex records follow, once the header ends”). Each element is described by a run of property lines that fix the fields of one record and their order. Properties come in two kinds.

A scalar property is one value of a named numeric type, written property <type> <name>. The types are the usual C-style set: char, uchar, short, ushort, int, uint, float and double (older files) or the explicit widths int8, uint8, float32, float64 and so on. Vertex position is three scalar float properties x y z; per-vertex colour is three uchar properties.

A list property is a variable-length list, declared property list <count-type> <item-type> <name>. It is how faces work, because a face can have any number of vertices. In property list uchar int vertex_index, each face record begins with a uchar giving the number of vertices in that face, followed by that many int vertex indices.

ASCII body for the header above
0 0 0 255 0 0        vertex 0: xyz + red
1 0 0 0 255 0        vertex 1: xyz + green
...                  (8 vertices total)
3 0 1 2              face: count=3, then vertex indices 0,1,2 (a triangle)
4 0 1 2 3            face: count=4, then indices 0,1,2,3 (a quad)

The leading 3 or 4 on each face line is the list count, not a coordinate. A triangle mesh is simply every face count equal to 3, which is why PLY is nicknamed the Stanford Triangle Format even though it permits arbitrary polygons.

Point clouds: vertices without faces

A large share of real PLY files contain only vertices and no faces at all. This is a point cloud, the natural output of LiDAR, depth sensors and photogrammetry: millions of measured 3D points, usually with colour or intensity, and no surface connecting them. In the header this looks like a big element vertex block and either no face element or one with a count of 0. Opening such a file shows a spray of dots, not a solid, which surprises people expecting a mesh. Turning a cloud into a watertight surface is a reconstruction step (for example Poisson surface reconstruction in MeshLab or CloudCompare), not something the file does on its own. The extra scanner properties, per-point confidence and intensity, ride along as ordinary custom vertex properties, which is exactly the extensibility PLY was designed for.

Exports and the mesh-to-CAD wall

The common jobs are straightforward mesh exports. Converting to STL is the top request, for 3D printing: open the PLY in MeshLab or Blender, clean and repair the mesh (fill holes, fix non-manifold edges), then export STL, accepting that STL keeps only geometry and drops the per-vertex colour. Converting to OBJ suits general rendering pipelines; exporting to glTF/GLB gives a single self-contained file for the web and AR; FBX targets game engines. Point-cloud PLYs can be dumped to a plain .xyz text point list.

One conversion class is genuinely impossible as a file operation: PLY to a precise CAD format such as STEP or DWG. A PLY is a polygon mesh or point cloud; STEP is exact B-rep solid geometry defined by mathematical surfaces. There is no faithful automatic path from a noisy scan mesh to clean parametric CAD. Getting there means retopologizing or reverse-engineering the scan into solids in a tool like Fusion 360 or Geomagic, a modelling job rather than a format conversion, and the one-click “PLY to STEP” converters that promise otherwise produce unusable results.

References

• Paul Bourke — PLY Polygon File Format specification
• MeshLab — official site
• Stanford 3D Scanning Repository

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.