Open .tw, .3oxz, .sdx, .meditmesh and .dentalproject files
A .tw, .3oxz, .sdx or .dentalproject file is a dental vendor export bundle rather than an image: a container — usually a renamed ZIP — holding the radiograph or scan plus the sidecar files that vendor software reads. Opening one means unpacking it and reading the file inside. Nothing is uploaded: the unpacking happens in the browser.
Stop archiving containers nobody can open
DodoDentist unpacks a vendor bundle on the way in and files the radiograph, the CBCT slices or the scan against the patient and the tooth, next to charting, treatment planning, reminders and billing.
Try DodoDentist freeDental units do not hand out a file. They hand out a bundle: the image, plus whatever the vendor workstation needs to redraw it the way the operator last saw it, plus a preview — and then they name the whole thing with an extension only that vendor has ever heard of. The container underneath is almost always a plain ZIP, because every vendor needed the same thing, several files travelling as one, and none of them wrote a new container format to do it.
That is why the practical advice you will find on forums — rename it to .zip and open it — usually works. It is also why it sometimes does not: the extension is the vendor branding, not a guarantee about the bytes. This page therefore looks at the bytes first and treats the extension only as a label, so a .tw that turns out to be a bare DICOM opens anyway, and a .3oxz that turns out not to be a ZIP is reported honestly instead of being forced through an unarchiver.
One Carestream bundle read here is worth describing in full, because it is the shape almost all of them take. A .tw from CS Imaging expanded to five files: csi_ps_export.dcm, which is the radiograph and in that case a For Processing lateral cephalogram; general.xml, processing.xml and annotation.xml, three sidecars the vendor software reads; and thumbnail.png, an ordinary preview picture. Sixteen megabytes of that bundle was the cephalogram. Everything else was bookkeeping.
Sort that bundle by filename and annotation.xml comes first, so any tool that opens "the first file" opens an XML sidecar. Sort it by size or take the first image and you get thumbnail.png, which is a picture of the radiograph rather than the radiograph. Neither is what the dentist wants. The rule this page applies instead is a ranking: a volume outranks a radiograph, which outranks a mesh, which outranks an ordinary picture — because a raster travelling beside a DICOM or a mesh is a preview of it, and every vendor bundle ships one.
A DICOM export dialog usually offers "For Presentation" and something like "keep current format", and the second one hands out the detector raw read-out. Its stored window describes the detector rather than the anatomy: the Carestream cephalogram read here stores a centre and width covering the whole fourteen-bit range while its pixels actually occupy a narrow band inside it, with the anatomy in the top fifth of what remains. Honour that stored window and you get a flat grey rectangle. That is not a broken file, and it is not a broken viewer — it is a raw image being shown raw.
The fix is two transforms rather than one. Deriving the window from the pixels instead of the header gets the image out of the grey, but no single linear window holds both soft tissue and bone at once, so a corrected raw ceph turns into a white skull with no internal detail. Radiographic density is the negative logarithm of X-ray intensity, and once the values are read in the log domain one window shows both. A presentation image is left completely alone, because its stored window is the manufacturer stating how they intend the image to be read.
Two of these have been checked against a real clinical file here. The rest are registered from vendor documentation, and the difference is stated plainly below rather than smoothed over, because a confident claim about a file nobody has opened is exactly how a dentist ends up trusting the wrong answer.
The .tw is verified: it is a ZIP, and its contents are described above. The tw comes from Trophy, the lineage Carestream acquired, which is also why the imaging application on a practice PC is called TW. That name collision is worth knowing, because searching the web for "tw file" mostly returns help with the Carestream application rather than with the export. A .trophy is registered here as the same kind of bundle, on documentation rather than on a file read in-house.
Both are ortho cases, and both are registered as ZIP containers from vendor documentation. 3Shape is also the source of the single most confusing habit in dental imaging: it names its own mesh case files .dcm, which is the DICOM extension. A viewer that trusted the extension would hand an intraoral scan to a radiograph reader and report a corrupt file. Identifying by content is what stops that, and it is why this page ignores what a file is called.
An .sdx is a Sidexis export, registered as a ZIP container from vendor documentation. Sidexis is a practice-wide imaging database rather than a file format, so an .sdx is best thought of as a parcel posted out of that database: the radiographs are inside it, and they are ordinary DICOM once they are out.
A .dentalproject is a whole CAD case rather than a model, which is why it does nothing without exocad installed. It is registered as a ZIP container from vendor documentation. Unpacking it lists what the laboratory actually sent, and if there is a mesh in there it opens anywhere — but the design state, the parameters and the case history only reopen in exocad. If you need the shape rather than the design, ask the laboratory for an STL or a PLY.
This one is verified, and the verified answer is a dead end: .meditMesh is a closed format with no public specification, so nothing outside Medit software opens it. The useful half is what sits beside it. A Medit case read here shipped its .meditMesh files alongside the PLY the same scanner also exports, and a PLY is an ordinary mesh that carries per-vertex colour — so the gingiva and the staining survive, which they would not in an STL. When somebody sends you a folder of .meditMesh files, the reply is to ask for the PLY.
These are not bundles at all. They are DICOM files whose exporter chose a different extension, and the bytes are identical to a .dcm. Renaming one to .dcm makes it open in any DICOM viewer, and dropping one here opens it directly, because content decides. If what you have is a plain radiograph rather than a container, the DICOM viewer on this site is the more direct tool.
Only ZIP is expanded. A 7-Zip, RAR or gzip container is recognised and named, but each needs its own decompressor and none of them is what a dental unit emits. A password-protected archive is refused rather than half-read, because a partially readable archive is a study with silently missing slices. Containers above 512 megabytes are refused too, since the whole archive has to be held in memory to read it, and a browser tab that dies mid-unpack helps nobody. In all three cases the answer is the same: unpack it on the desktop and open one file from it.
A CBCT export is the case where that matters most. A cone beam scan arrives as hundreds or thousands of single-frame DICOM slices, often zipped, sometimes with a bundled Windows viewer that only runs on Windows. Two or more DICOM files in one container are treated here as one acquisition and opened as a scrollable stack, decoded a slice at a time — but the container still has to be under the size ceiling to get that far.
Drag the .tw, .3oxz, .sdx, .dentalproject or .meditmesh onto the drop zone, or click it to choose the file. Nothing is filtered by extension, because dental units name their exports in ways no list keeps up with.
Every file the container held is listed with what it actually is — a radiograph, a mesh, an XML sidecar, a preview thumbnail — identified from its bytes rather than from its name.
The file worth looking at opens by itself. A volume outranks a radiograph, which outranks a mesh, which outranks an ordinary picture, so the preview thumbnail every vendor bundles is never what appears.
| Extension | Vendor | Container | Opens here | How we know |
|---|---|---|---|---|
| .tw | Carestream Dental | ZIP | Yes | Read from a real clinical file |
| .trophy | Carestream Dental | ZIP | Yes, if it is a ZIP | Vendor documentation |
| .3oxz / .3ox | 3Shape | ZIP | Yes, if it is a ZIP | Vendor documentation |
| .sdx | Dentsply Sirona | ZIP | Yes, if it is a ZIP | Vendor documentation |
| .dentalproject | exocad | ZIP | Yes, if it is a ZIP | Vendor documentation |
| .meditmesh | Medit | Closed format | No — ask for the PLY | Read from a real clinical file |
| .dcm30 / .dc3 / .dicm | Generic | Plain DICOM | Yes | Identical bytes to a .dcm |
That table is a naming and routing hint, never a gate. Nothing here refuses a file because its extension is missing from the list: an unregistered .zip from a dental unit is unpacked exactly the same way, and a registered extension whose bytes disagree is reported rather than forced. No enumeration keeps up with what dental units name their exports, and a greyed-out file picker is a dead end a dentist cannot argue with.
A .tw is a Carestream Dental bundle: a ZIP under a different name. Rename it to .zip and any unarchiver opens it, or drop it on this page and it is unpacked in your browser. A real one read here held csi_ps_export.dcm — the radiograph, a For Processing lateral cephalogram — beside general.xml, processing.xml, annotation.xml and thumbnail.png.
Both are 3Shape ortho cases, and both are registered here as ZIP containers on the strength of vendor documentation rather than a file anyone here has opened. So the honest answer is: try unpacking it. If the bytes really are a ZIP the contents are listed; if they are not, this page says so instead of guessing.
No, and neither will anything else outside Medit software. .meditMesh is a closed format with no public specification. The useful part is that a Medit case exports a PLY alongside its .meditMesh files, and a PLY is an ordinary mesh that any 3D viewer opens with the scan colour intact. Ask whoever sent the case to send the PLY.
An .sdx is a Dentsply Sirona Sidexis export. It is registered here as a ZIP container on vendor documentation rather than on a file read in-house, so this page attempts to unpack it and reports what it actually found. Whatever radiograph comes out is the file worth archiving; the wrapper is not.
A .dentalproject is an exocad project: the whole CAD case rather than a single model, which is why double-clicking it without exocad does nothing. It is registered here as a ZIP container on vendor documentation. If the bytes are a ZIP, unpacking lists the meshes and sidecars inside, but the design state itself only reopens in exocad.
Because it is a DICOM file wearing a different extension, and whatever you opened it with only recognised .dcm. The bytes are identical. Rename it to .dcm and any DICOM viewer takes it, or drop it here — this page identifies files by their contents, so the extension decides nothing.
No. This page has no upload endpoint. The archive is unpacked and the image decoded by your own browser, on your own machine. That matters more here than for most tools, because a dental bundle normally contains a DICOM whose header carries the patient name, identifier and date of birth.
Not to see what is inside. A vendor bundle is a container, and unpacking a container needs no vendor software. The vendor application is needed only to reopen the case the way the vendor stored it, with its annotations and its layout. The radiograph or the mesh inside opens anywhere.