Tác giả: Huy Nguyen · ·
People convert STL to OBJ when something downstream would rather have an OBJ: a renderer, an older game pipeline, a university assignment, a mesh-processing script, or a modelling package that imports OBJ more cleanly than STL. It is also the first step if you want to give a printable model UV coordinates and a material, because an STL has nowhere to put them.
This is a gentle conversion, in the sense that OBJ can hold everything STL can and a great deal more. The catch is that converting does not fill the extra room. You get the same triangles, described better, plus a few practical surprises about what actually lands in your downloads folder.
We ran two STL files through the same converter this page uses today, unpacked the results, read them line by line and re-imported them in Blender 5.1. The numbers below are from that run.
What the test conversions kept and lost
The first input was a CAD bracket exported as a 51,684 byte binary STL: 1,032 triangles built from 516 unique points, a 40 by 20 by 10 mm plate with a hole and filleted edges. The second was a scan-shaped mesh of 320 triangles and 162 points, 16,084 bytes, authored in metres. Both behaved the same way.
| What went in | What came out | Verdict |
|---|---|---|
| 1,032 triangles | 1,032 triangular faces | Kept exactly. Nothing decimated, nothing smoothed, nothing retopologised |
| 3,096 vertex records, 516 of them unique | 516 vertex lines plus an index list | Improved. Duplicate corners are welded into one shared vertex |
| One flat normal per triangle | 291 normal lines, each face pointing at one of them | Kept. Identical facet normals are shared rather than repeated |
| No colour and no material, because STL has none | A companion MTL file containing no material at all | Honest. Nothing is invented to fill the gap |
| No texture coordinates | No texture coordinates | Unchanged. OBJ has room for UVs but there were none to carry |
| 40 by 20 by 10 mm | The same 40, 20 and 10, with the height now on the Y axis | Kept, and written to the OBJ Y-up convention |
| One unnamed solid | One object under a generated temporary name | Workable, but you will want to rename it |
| 51,684 bytes of binary STL | A 10,519 byte ZIP holding a 50,131 byte OBJ | The download is 80 percent smaller, the OBJ inside it is not |
Your download is a ZIP, and that is on purpose
This catches people out, so it is worth saying first: converting to OBJ gives you a ZIP archive, not a bare .obj file. Unzip it and you will find two files, bracket.obj and bracket.mtl in our test.
The reason is that an OBJ is never really one file. The geometry lives in the .obj and the materials live in a .mtl next to it, referenced by a single mtllib line near the top. A converter that handed you only the .obj would be handing you a file with a dangling reference, so both are bundled together.
Keep the two files in the same folder when you import. Most software looks for the .mtl by the name written inside the .obj, in the same directory, and silently gives up if it is not there.
The MTL file inside is empty, and that is correct
The bracket.mtl we got back is 51 bytes: two comment lines and nothing else. There is no material block in it, and the OBJ contains no usemtl line pointing at one.
That is the honest result rather than a bug. An STL file has no colour, no material and no texture, so there is nothing to translate. A converter that filled the gap with an invented grey material would be making up data about your model.
What it means for you is simple: if you want a material, you add it after the conversion, in Blender or whatever you import into. The empty MTL is a placeholder you can write into, not something that failed.
Duplicate vertices get welded, and that is the real benefit
A binary STL stores three full vertex positions for every triangle and keeps no shared list, so a corner where six triangles meet is written six times over. Our bracket therefore held 3 times 1,032, or 3,096 vertex records, for a shape that only has 516 distinct corners.
The converted OBJ has 516 v lines and refers to them by index, which is how OBJ is designed to work. The scan went the same way: 960 records in, 162 v lines out. Re-imported in Blender, both came in at exactly those vertex counts with unchanged coordinates.
This matters if you intend to do anything to the mesh. Welded vertices are what make it possible to select an edge loop, smooth a surface, unwrap UVs or run a decimation filter without the mesh falling apart into loose triangles. It is the main reason mesh-processing tools prefer OBJ or PLY over STL.
Triangles stay triangles: you do not get your quads back
All 1,032 faces in the output OBJ are three-sided. If your STL came from a model that originally had quads, they are not restored, and no converter can restore them, because the STL threw away the information about which triangle pairs used to be one face.
The same is true for curved surfaces. Our bracket has filleted edges that exist in the OBJ as a fan of flat triangles, exactly as they existed in the STL. Nothing is re-smoothed and no curvature is recovered.
If you need quads, that is retopology, and it is modelling work: the Remesh modifier or a retopology add-on in Blender, or the relevant filters in MeshLab. If you need the true curved surface back, you need the original CAD file, not a converted mesh.
What OBJ can hold that your converted file does not fill
OBJ supports texture coordinates, named materials, several named objects and smoothing groups. Converting from STL leaves all of those empty, because the STL never had them. That is not a shortcoming of the conversion; it is why people convert in the first place.
The useful way to think about it: this conversion gives you a file you can start adding to. Import the OBJ, unwrap it, assign a material, split it into parts, name them, and export OBJ again. None of that is possible while the geometry is locked in an STL.
Which way up, and that strange object name
The OBJ convention is Y-up, and the converter follows it. Our bracket is 40 by 20 by 10 mm with the 10 mm height on Z inside the STL, and in the output OBJ that 10 sits on the Y axis instead. The millimetre numbers themselves are untouched.
Blender handles this correctly on its own: with the default OBJ import options the bracket came in measuring 40 by 20 by 10 in world space, standing the right way up. We tried forcing the up axis to Z and that is what produces a part lying on its side, measuring 40 by 10 by 20. So leave the import axis settings alone unless the model genuinely arrives flat.
One cosmetic annoyance: the object inside the OBJ is named with a generated temporary string rather than your file name, so it shows up in an outliner as a long run of digits. Rename it after import, or edit the o line at the top of the .obj in any text editor.
File size: the download shrinks, the OBJ does not
The ZIP you receive is much smaller than your STL: 10,519 bytes against 51,684, about 80 percent off. That is the ZIP compression doing its job on very repetitive text.
The OBJ inside is a different story. Unpacked it is 50,131 bytes, essentially the same as the 51,684 byte STL it came from. The saving from welding 3,096 vertex records down to 516 is almost exactly cancelled by the cost of writing coordinates as decimal text instead of binary floats. The scan behaved identically: 16,084 bytes in, 15,260 bytes of OBJ out.
So do not convert to OBJ expecting a smaller working file. Convert to OBJ because you want an indexed, editable mesh. If size is the goal, PLY or GLB keep the welding and stay binary.
When not to convert STL to OBJ
- If your target software already reads STL, skip it. Blender, MeshLab, CloudCompare, every slicer and most CAD packages import STL directly, and the conversion adds nothing.
- If you are hoping to recover an editable CAD solid, this will not do it. A mesh cannot become a parametric body by changing container, no matter which mesh format you pick. You need the original STEP or native CAD file.
- If you want colour, there is none to recover. The STL never stored any, so the OBJ arrives with an empty material file. Colour has to be added by hand afterwards.
- If you only want to view or measure the model, use a viewer. A conversion is a slower way to answer the same question.
- If you want to shrink the file, OBJ is the wrong move. Unpacked it is about the same size as the STL.
Doing the same job on your own machine
- Blender is the straightforward route: File, Import, STL, then File, Export, Wavefront OBJ. The exporter has its own options for normals, UVs and whether to triangulate, and it also writes the .mtl next to the .obj.
- Blender welded our test STL to its 516 unique vertices on import, but an STL from a 3D scanner can have duplicate corners whose coordinates differ in the last decimal and those will not merge on their own. If you need them merged, select all in Edit Mode and use Mesh, Merge, By Distance before exporting.
- MeshLab is the better choice for large or scanned meshes. Import the STL and use Export Mesh As to write an OBJ, with checkboxes for which per-vertex properties to include.
- FreeCAD can also do it through its Mesh workbench, which is convenient if the STL is part of an engineering project you already have open.
Limits here, and what happens to your file
- Free: up to 30 MB per file, 10 conversions per hour, 2 running at the same time, no account needed.
- Pro: up to 1 GB per file, 50 conversions per hour, 5 at the same time.
- Uploaded files and their converted results are deleted from our servers within 1 hour of upload.
- From an STL this site converts to OBJ, GLB, GLTF, FBX, 3MF, DAE and PLY. Our two test files were binary STL, which is what most software writes.
Tested on 29 October 2026 with two binary STL files: a CAD bracket of 1,032 triangles and 516 unique points measuring 40 by 20 by 10 mm, and a scan-shaped mesh of 320 triangles authored in metres. Both were converted here, the returned ZIP archives were unpacked and their OBJ and MTL contents counted line by line, and both meshes were re-imported in Blender 5.1 to confirm vertex, face and dimension counts.