Open colour intraoral scans in your browser
A PLY file is a 3D mesh, usually an intraoral or a lab scan, that stores a colour value for every vertex — which is why a scan exported as PLY keeps the gingiva, the stain and the line where enamel stops, while the same scan exported as STL arrives plaster-grey. PLY files open in a browser without installing anything.
Keep the colour scan on the patient record
DodoDentist keeps intraoral scans, radiographs and CBCT exports against the patient and the tooth, and opens them in the same viewer you have been using on this page — beside charting, treatment planning, reminders and billing.
Try DodoDentist freeAn intraoral scanner with colour capture records a shade for every point of surface it measures. What happens to that shade next is decided entirely by the export format. Choose STL and the colour is gone before the file is written — not compressed, not degraded, gone, because an STL triangle has nowhere to put it. Choose PLY and the same scan arrives with a colour attached to every vertex, in one self-contained file.
This is the surprise a practice meets the first time it sends scans out. The model on the scanner screen shows inflamed gingiva, a stained margin, the line where enamel stops. The file that reaches the laboratory is a uniform plaster grey, and nothing went wrong in transit: the export dialog decided it.
An STL is a list of triangles and nothing else. Each triangle is stored as three corner coordinates plus a normal vector, and every vertex is written out again for each triangle that touches it — there is no shared vertex list and no index. There is no unit either: a millimetre and an inch look identical in the file, which is why importers ask. And there is no colour. A couple of vendor extensions have used the two spare bytes at the end of each triangle record to carry one, but they are not part of the format and cannot be relied on.
PLY — the Stanford Triangle Format — is self-describing. It opens with a plain-text header that declares each element in the file and each property of that element, and the body is exactly what the header said it would be. A colour scan declares x, y and z for every vertex and then red, green and blue beside them, followed by a face list that refers to those vertices by index.
Two consequences matter in a clinic. Colour sits on the vertices, so it is interpolated smoothly across each triangle instead of being painted on a face at a time; and it lives in the same file as the geometry, so there is nothing to lose in an email or a shared folder. A PLY can be written as text or as binary in either byte order, and the header line says which — this viewer reads all three.
| Format | Carries colour | Files that must travel together | Where it comes from |
|---|---|---|---|
| PLY | Yes — one colour per vertex | One | An intraoral scanner exporting a colour scan |
| STL | No — the format has no field for it | One | Intraoral scanners, lab CAD, 3D printing |
| OBJ | Yes — per vertex, or as a material and a texture | Up to three: .obj, .mtl, image | Design and mesh software such as exocad, Meshmixer or Blender |
| glTF / GLB | Yes — materials and textures | One as .glb, several as .gltf | Web viewers and rendering pipelines |
The same scan in another format: open an STL file · open an OBJ file · open a DICOM radiograph
OBJ is the awkward middle. It can carry colour two ways: some writers add three extra numbers to each vertex line, which behaves like PLY, while the classic route is a companion .mtl material file plus an image for the texture. That second route is three files that have to stay together, and the .mtl is the one that gets left behind — at which point the mesh opens grey and looks exactly like an STL.
glTF and its binary form GLB solve the same problem from the other end: a .glb packs geometry, materials and textures into a single container. It turns up in dentistry when a scan has already been through a web viewer or a rendering pipeline.
None of this makes STL a bad format. A 3D printer builds in one material, so colour has nothing to do there, and STL has been read by design software and printing pipelines for decades — which is why it stays the safe default when you do not know what the other end can open.
The practical answer is to export both when a case leaves the practice: STL for whoever is going to design or print from it, PLY for the record. Re-exporting a PLY as STL takes seconds — the view toggle above does exactly that, so you can see what it costs. Going the other way is impossible — the colour was never in the STL to begin with.
A grey mesh is a plaster cast with better tolerances. A colour one shows where the gingiva is inflamed, where a margin is stained, where enamel ends and a restoration begins — the things you would look for in the mouth rather than on the model. It is also easier to talk a patient through, because it looks like their own teeth instead of an abstract shape.
This page has no upload endpoint. A dropped file is read with the browser File API, parsed in the tab and drawn with WebGL, all on your own machine — the scan never crosses the network. That is a property of how the page is built rather than a promise about how we behave with your files: there is nowhere for the file to go.
The file is also identified by what is inside it rather than by its extension, which matters more in dentistry than almost anywhere else: 3Shape names its own mesh cases .dcm, the same extension a radiograph uses, and plenty of exports arrive with no extension at all.
A PLY file is a 3D mesh: a list of vertices and the triangles that join them, written by an intraoral scanner, a desktop model scanner or design software. What separates it from STL is that it can store extra properties on every vertex, and colour is the one that matters clinically — a PLY from a colour scan carries a red, a green and a blue value for each vertex.
Drop it onto this page and it is drawn in your browser, with no upload and no signup. Desktop options exist too — MeshLab, Blender and most CAD packages read PLY — but for a quick look at a scan a colleague or a laboratory sent, a browser viewer needs nothing installed.
No. An STL triangle has room for three corner coordinates and a normal vector and nothing else, so a colour scan exported as STL arrives grey. A couple of vendor extensions have used the two spare bytes at the end of each triangle record to smuggle a colour in, but they are not part of the format and cannot be relied on.
Because it was exported as STL. The colour was dropped by the export, not by the viewer that opened the file, and it cannot be recovered from the STL afterwards. Export the same scan again as PLY and the colour is there.
PLY, when the choice is offered. Both can carry colour, but OBJ normally keeps it in a separate .mtl material file with an image beside it, which makes three files that have to stay together; a PLY is one file with the colour inside it. OBJ is the better answer when the scan has to keep a photographic texture rather than one colour per vertex.
No. This page has no upload endpoint. The file is read in your browser with the File API and drawn on your own machine, so it never crosses the network.
Colour-capable intraoral scanners generally offer PLY in the export dialog beside STL — Medit, for one, writes a PLY alongside its own proprietary case file. If the dialog you use offers STL only, no setting inside it can preserve the colour, because the format has nowhere to keep it.
Yes, as long as the browser can give the page a WebGL context; the viewer says so plainly when a device cannot. Dragging a finger across the model rotates it. A full arch is still easier to inspect on a larger screen than on a phone.