Dental CAD File Formats: STL, PLY, OBJ and What Labs Accept

A digital case lives or dies on the file you send. When a clinic asks about dental CAD file formats, what it really wants to know is which export will let the lab open the scan, design the restoration and avoid a wasted round of questions. Most delays attributed to “the lab” are actually format or export problems at the source. This guide explains what the common formats carry, where exports go wrong, and what to confirm before you send case data, building on the lab’s digital workflow and the steps in sending STL files.

Why format matters

A scan file is the working model the lab designs against. If the format drops information, the design inherits the gap. Some formats store only the outer surface; others store color or texture; a few are design application files that carry the actual construction history. The wrong choice can mean a model that looks closed but is full of holes, a shade reference that never arrives, or a file the lab’s software cannot import at all. Choosing a format is therefore a clinical decision about what the lab needs to see, not just a button in the scanner software. This is why dental CAD file formats deserve a moment of attention at the start of every digital case rather than after a file fails to open.

STL

STL is the default for dental scans and the format most labs accept without question. It describes a surface as a mesh of triangles and carries no color, no units label you can trust, and no construction history. That is usually enough for a crown or bridge, because the lab needs the geometry, not the texture. The catch is quality: a low-resolution STL looks faceted and can hide a margin, while a very dense one becomes a large file with no real benefit. For most fixed work a clean, moderately dense STL file is the safe choice, and it is what the lab’s import pipeline expects first.

PLY and OBJ

PLY and OBJ extend beyond plain geometry. PLY can carry vertex color, which helps when the scan records a shaded model the lab can read for shade context. OBJ supports material and texture references and is common in broader 3D work, though less universal in dental pipelines than STL. Both are useful when color or texture matters, but they are also easier to break: a missing companion file or an unrecognized material reference leaves the lab with an incomplete model. Use them when the lab asks for color data; otherwise STL keeps the hand-off simple.

Native CAD and design files

Native files from a scanner or design application carry the most information but the least portability. They open in the original software and may not import elsewhere without conversion. Sending a native file can help when the lab uses the same system and wants to adjust the design directly, but it should not replace a clean exported STL as the deliverable. Treat the native file as a supplement, not the primary record, unless the lab specifically requests it for a collaborative design step.

Scan resolution and file size

Resolution and size pull in opposite directions. Too little resolution loses the finish line; too much produces a file that is slow to transfer and slow to process, with no gain in fit. A reasonable target is enough density that the margin reads clearly without obvious facets, and no more. The lab can usually tell from the mesh whether the scan was adequate, and an oversized file delays the start of design rather than improving it. Match the resolution to the restoration, not to the scanner’s maximum setting.

Common export problems

The recurring export faults are predictable. A file exports with the wrong units, so a model meant to be millimeters arrives as something else. A scan has holes at the margin because the prep was not fully captured. Multiple disconnected bodies get exported together, leaving the lab to guess which is the working model. A color format arrives without its companion files. Each of these is fixed at export time, which is why the checklist in sending STL files starts before the file leaves the clinic.

Naming and case identification

A correctly formatted file with a useless name creates the next delay. The lab receives many scans a day, and “scan1.stl” tells no one which patient or which tooth it is. Name the file with the case ID, the patient identifier you both use, and the arch or tooth where it matters. Keep the prescription and the file linked by that same identifier so the design step starts from the right record. Identification is part of the data package, not paperwork added later.

What to confirm with the lab

Before sending, confirm three things: which format the lab imports first, whether color data is wanted for the case, and how the file should be named and linked to the prescription. A short message avoids a wrong export and a returned case. For digital denture support and other multi-archive work, ask how the lab wants the separate scans bundled, because full-arch cases carry more files than a single crown. The confirmation takes minutes and removes the most common source of avoidable delay.

Next step

Prepare one scan as a clean STL with a clear name and a matching prescription, then send it to confirm the import path works. To start, send a case to the lab, or request a price list to see which digital and conventional services the workflow supports.