What is an OBJ file?

OBJ is a plain-text format you can open in any editor. It stores shapes and coordinates rather than pixels, so it stays sharp at any size — a logo scaled to a billboard loses nothing. It is used for moving data between programs and editing.

The extension is .obj, and the full name is Wavefront Object. Both matter less than what the file can hold, which is what the rest of this page is about.

Wavefront Technologies published it in 1992.

A format that has been readable for that long is a format worth trusting with something you want back in ten years.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

OBJ stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

Blender, MeshLab and Maya read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

OBJ is meant to be opened and changed. Keep the file in this format for as long as the work is going on, and export from it whenever a finished copy is needed.

OBJ has been the lowest common denominator of 3D since 1992. Every modelling program, every game engine, every renderer and every online viewer imports it, which is not true of any other mesh format, and it survives on that alone — the specification is thirty years old, it lacks features everything else has, and none of that matters when the question is whether the other person can open the file.

It is plain text, which is the other half of the appeal. A vertex is a line beginning v followed by three numbers; a face is a line beginning f followed by the vertices it joins. You can open a model in a text editor and understand it, which for a 3D format is unusual enough to be worth saying.

An OBJ contains geometry and nothing else. Colours, materials and textures live in a separate .mtl file that the OBJ names on its first few lines, and the texture images are separate files again, named by the MTL.

So a model is really a folder: one .obj, one .mtl, and however many image files. Send only the .obj — which people do constantly, because it is the file with the recognisable name — and the recipient sees untextured grey geometry. This is far and away the most common problem with the format, and the fix is to send everything or to zip the folder.

A texture is a flat image, and the model has to say which part of that image belongs on which part of the surface. Those are UV coordinates — a second set of numbers, one pair per vertex, mapping the mesh onto the picture.

They are stored in the OBJ, so they survive the journey even when the materials do not. That is worth knowing when a model arrives untextured: if the UVs are intact, reattaching a texture is a two-minute job in any modelling program. If the file was exported without them, somebody has to unwrap the mesh again, and that is real work.

The numbers in an OBJ have no dimension attached. A cube ten units across might be ten millimetres, ten centimetres or ten metres, and the file does not say — each program applies its own assumption on import, which is why a model arrives either microscopic or the size of a building.

Orientation is the same story. Some software treats Y as up, some treats Z as up, and the format takes no position, so models routinely arrive lying on their side. Both problems are fixed in seconds by scaling and rotating on import, and both are worth checking before anything is measured or printed.

Storing every coordinate as decimal text costs a great deal of space. The same mesh as a binary STL or PLY is typically three to five times smaller, and a detailed scan exported as OBJ can run to hundreds of megabytes.

It also compresses extremely well, for the same reason — a zipped OBJ is a fraction of its own size, since decimal text is enormously redundant. For transferring or archiving a model, zipping is close to free and removes most of the objection to the format.

No animation, no rigging or bones, no scene hierarchy, no cameras or lights, and no modern material model — the MTL format describes a shading approach from the early 1990s, so metalness and roughness maps have no proper home and are passed through by convention rather than by specification.

This is why glTF exists and why game pipelines use it instead. OBJ is for handing a static shape from one program to another, and it does that better than anything. For a rigged character, an animated scene, or physically based materials, it is the wrong file.

Slicers accept OBJ, and the geometry converts to STL cleanly since STL is a strict subset of what OBJ can express — triangles and nothing else. What matters is whether the mesh is watertight: every edge shared by exactly two faces, no holes, no inverted normals.

Models built for rendering frequently are not. A surface with no thickness looks perfect in a viewport and is unprintable, because a slicer cannot decide what is inside it. Running the file through a repair tool before printing catches most of it, and it is faster than discovering the problem after four hours on the printer.