What is a PLY file?

PLY is a binary format, meaningful only to a program that knows it. It stores shapes and coordinates rather than pixels, so it stays sharp at any size — a logo scaled to a billboard loses nothing. It is used for scanning and moving data between programs.

The extension is .ply, and the full name is Polygon File Format. Both matter less than what the file can hold, which is what the rest of this page is about.

Stanford University published it in 1994.

A format that has been readable for that long is a format worth trusting with something you want back in ten years.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

PLY stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

MeshLab, Blender and CloudCompare read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

PLY is meant to be opened and changed. Keep the file in this format for as long as the work is going on, and export from it whenever a finished copy is needed.

PLY was written at Stanford in the mid-1990s for range-scanner data, and that is still what it mostly holds. Photogrammetry software, handheld and structured-light scanners, lidar tools and the Stanford models themselves all speak it, because it was designed for exactly the awkward thing scanners produce: millions of measured points, each carrying properties the scanner recorded.

The design that made it last is that the properties are declared rather than fixed. The header lists what each vertex carries — position, colour, normal, confidence, intensity, anything a particular instrument measures — and readers take what they understand. A format from 1994 can therefore carry data from an instrument built last year.

OBJ paints a surface with a texture image mapped onto it. PLY normally does something simpler: every vertex carries its own colour, measured at that point.

For a scan that is exactly right, because the scanner measured colour per sample and there is no unwrapped surface to map an image onto anyway. It also means the colour resolution is the geometry resolution — a coarse mesh has coarse colour, and detail can only be added by adding points. That is the trade against textures, where a low-polygon model can carry a very detailed image.

This causes real confusion. A PLY can be a list of points with no connections at all — a cloud — or a proper mesh with faces joining them. Both are valid, both have the same extension, and a program expecting one will do something unhelpful with the other.

A cloud opened in a program that wants a mesh appears as a faint dust of dots or as nothing at all. It is not corrupt; there are simply no faces to draw. Turning a cloud into a surface is reconstruction — Poisson or ball-pivoting in MeshLab or CloudCompare — and it is a processing step with parameters to choose, not a format conversion.

As with STL, the header declares which encoding follows. ASCII is readable and roughly four times larger; binary is what any real scanner writes.

Even in binary these files are big, because the counts are. A phone photogrammetry scan of an object routinely produces two to five million points, and a lidar sweep of a room produces tens of millions. At around fifteen bytes per point with colour, a hundred-million-point survey is a gigabyte and a half before anything has been reconstructed. That is normal for the format rather than a sign of a bad export.

Raw output is never finished. There is background — the table, the floor, the room — that has to be cropped away. There are outliers, stray points floating where the scanner misjudged a reflection or an edge. There are holes where the instrument could not see, under the object and behind every overhang.

Then decimation, because a five-million-point mesh is unusable in anything downstream, and hole filling, and only then a mesh worth texturing or printing. MeshLab and CloudCompare are the free tools for all of it. The scanner produces measurements; turning measurements into a model is a separate job and the larger one.

Converting PLY to STL is the usual last step, and it discards the colour — STL has none — while keeping the shape. That is generally acceptable, since a single-material printer could not have used the colour anyway.

The failure to expect is watertightness. Scans are riddled with holes by their nature: nothing was measured underneath the object, and detail is missing wherever the instrument had no line of sight. A slicer needs an unambiguous solid, so the holes have to be filled and the mesh checked before the STL is written. Skipping that produces a file the slicer refuses or, worse, one it accepts and interprets its own way.

If the model is going into a game engine or a web viewer, convert to glTF: it carries textures, materials and a scene, and it is built for delivery rather than capture. If it is going into a modelling program to be edited, OBJ is more universally accepted. If it is going to a printer, STL.

PLY earns its place at the capture end of the pipeline, where per-vertex properties and an extensible header are exactly what is needed. Keep it as the archive of what was actually measured, and generate the delivery formats from it — the reverse, reconstructing measurements from a decimated mesh, is not possible.