Free online PLY converter. Convert PLY to GLB, OBJ, STL, GLTF and more online — no limits, no watermark.
.ply onto the page. Both the ASCII and the binary variant are read, including files that carry per-vertex colour and normals straight out of a photogrammetry or laser-scan pipeline.<model-viewer>, with per-vertex colour carried throughComing the other way, OBJ to PLY, STL to PLY and GLB to PLY put an edited or downloaded model back into the format MeshLab and CloudCompare are happiest with.
PLY — the Polygon File Format, also known as the Stanford Triangle Format — came out of Stanford University's graphics lab in 1994, developed by Greg Turk and colleagues under Marc Levoy to store the output of 3D scanners. Its design goal was flexibility rather than compactness: a PLY header declares elements and then declares arbitrary properties on each element, so a vertex can carry position, colour, surface normal, texture coordinates and even a scanner confidence value, and a file can define new properties a reader has never seen. It exists as a human-readable ASCII variant and a compact binary variant, and it remains the default export of most photogrammetry software, MeshLab and CloudCompare.
That openness is exactly what makes PLY great for capture and awkward for everything downstream:
.ply shared with a client is a file they cannot open.<model-viewer>, Babylon.js and AR quick-look all want.| Format | Origin / standard | Structure | Stores per-vertex colour | Best for |
|---|---|---|---|---|
| PLY | Stanford, 1994 (Greg Turk et al.) | Header-declared elements and arbitrary properties; ASCII or binary | Yes, natively | 3D scans, point clouds, photogrammetry, research data |
| GLB / glTF | Khronos Group; glTF 2.0 is ISO/IEC 12113:2022 | JSON scene graph plus binary buffers; GLB packs both into one file | Yes, as the COLOR_0 vertex attribute |
Web, AR/VR, real-time engines, product viewers |
| OBJ | Wavefront Technologies, 1980s | Plain text vertices and faces; materials in a sidecar .mtl |
No — colour lives in the material file | Editing and hand-off between 3D applications |
| STL | 3D Systems, 1987 | An unstructured list of triangles with facet normals | No | Slicing and 3D printing |
| 3MF | 3MF Consortium; ISO/IEC 25422:2025 | XML inside a ZIP package (OPC), with extensions for materials and production data | Yes, in the full specification | Modern slicers and Windows 3D tooling |
This is the single most common way a PLY conversion goes wrong, and it has nothing to do with the converter. A PLY can describe either a mesh — vertices plus an element face list that connects them into triangles — or a point cloud, which is just vertices with no connectivity at all. Raw scanner output and photogrammetry sparse clouds are usually the latter.
Every format on the output list except PLY itself describes surfaces. When a point cloud with no face list is exported to STL, OBJ, 3MF or GLB, the exporter has no connectivity to work from and falls back to treating consecutive vertices as triangle corners. We reproduced this with a deliberately face-free four-point PLY: the STL export came back with two facets stitched from arbitrary vertex triples — a valid file describing geometry that does not exist.
The fix is a meshing step, and it belongs upstream of any format conversion:
element face line with a non-zero count, you have a point cloud.| Target | Encoding written | Per-vertex colour | Materials / textures | Notes |
|---|---|---|---|---|
| GLB | Binary glTF, one file | Yes — written as the COLOR_0 attribute, which glTF viewers multiply into the base colour |
Carried where the source has them | The best target for a coloured photogrammetry scan |
| glTF | glTF JSON | Yes, same COLOR_0 attribute |
Carried where present | Readable and diff-able; larger than GLB |
| OBJ | Plain-text OBJ | No | No .mtl sidecar is produced |
Geometry hand-off only — re-apply materials in your editor |
| STL | ASCII STL (solid … endsolid) |
No — the format has no field for it | No | Exactly what a slicer wants; expect a single-colour print |
| 3MF | Minimal 3MF package: [Content_Types].xml, _rels/.rels and 3D/3dmodel.model |
No — the geometry-only writer emits vertices and triangles | No | Units are declared as millimetres; scale in your slicer if the scan was in metres |
| PLY | ASCII PLY | Yes | n/a | Useful for converting a binary PLY to a readable one, or normalising an odd variant |
To GLB and glTF, yes. We verified this on a colour-carrying PLY: the loader reads the red/green/blue vertex properties into a colour attribute and the glTF exporter writes it out as a COLOR_0 accessor, which glTF viewers multiply into the material's base colour. To OBJ, STL and 3MF, no — OBJ keeps colour in a separate .mtl file that is not produced here, STL has no colour field at all, and the 3MF writer emits geometry only. If the scan's colour is the point of the model, GLB is the target.
Because the preview is a geometry check. PLY and STL sources are mounted with a plain shaded material so that surface detail, holes and stray geometry read clearly against even lighting — vertex colour would make a noisy scan harder to inspect, not easier. The colour data is still in the file: convert to GLB and open the download in any glTF viewer to see it applied.
No, and that is STL's limitation rather than the conversion's. STL, defined by 3D Systems in 1987, stores nothing but triangles and their facet normals — there is no field for colour, material or texture. For colour printing you need a format that carries it, and the full 3MF specification (ISO/IEC 25422:2025) does support colour and materials; note that the 3MF files produced here are geometry-only, so a coloured scan destined for a colour printer is better exported as GLB and taken into your slicer's own import path.
It has to be a mesh for any surface format to make sense. A point cloud has vertices but no element face list, and STL, OBJ, 3MF and glTF all describe surfaces — so the exporter falls back to connecting consecutive vertices, which produces triangles that do not correspond to anything in the scan. Run Poisson reconstruction in MeshLab or CloudCompare first, then convert the resulting mesh. Converting a cloud to another cloud format is fine; converting a cloud to a surface format is not a format problem.
Dense scans are large because they store a position, a normal and often a colour for every one of millions of vertices, and ASCII PLY writes each of those numbers as text. Converting to binary GLB usually produces a much smaller file simply because it stores the same values as packed binary. But a format change re-packs the geometry, it does not simplify it — the real reductions come from decimation (reducing the polygon count in MeshLab or Blender) or from Draco mesh compression, both of which are separate steps you run before export.
They were built for different jobs. PLY came from a 3D-scanning lab and is property-driven: any element can carry any list of named properties, which is how colour, normals and scanner confidence end up attached directly to each vertex. OBJ came from Wavefront's animation software and is an interchange format: it stores vertices, texture coordinates and faces as plain text, and puts materials in a separate .mtl file. If you are moving a scan into Blender or Maya to clean it up, PLY to OBJ is the usual route; if you are publishing it, GLB is the better target.
GLB unless you have a reason not to. They contain the same data: glTF 2.0 is a JSON scene description with binary buffers, and GLB is that same content packed into a single binary file. One file means one request, no relative-path problems and no missing sidecar when someone re-hosts your model, which is why <model-viewer> embeds and AR quick-look normally use .glb. Choose .gltf when you want to read or script against the JSON — inspecting the accessor list, checking that COLOR_0 is present, or patching material values by hand.
PLY does not record units at all — the header describes properties, not scale — so the numbers in your file mean whatever the capture software intended, commonly metres for photogrammetry and millimetres for structured-light scans. glTF's convention is metres, and the 3MF file written here declares unit="millimeter". Nothing rescales the coordinates during conversion, so if a model imports a thousand times too large or too small, that is a unit mismatch to fix in your slicer or editor rather than a conversion fault.
No. The 3D conversion runs in your browser using three.js loaders and exporters — the file is parsed, converted, previewed and written back out as a download on your own machine, with no account and no watermark. For proprietary scans, unreleased product geometry or client work under NDA, that removes the question of what a third party does with the file entirely.