10 min read

Text-to-CAD file formats: what comes out and whether it's usable

Text-to-CAD tools output STEP, STL, glTF, OBJ, and DXF. Only one of those formats matters for real engineering work, and it's the one most tools handle worst.

Quick answer

STEP (AP214/AP203) is the only text-to-CAD output format suitable for engineering work because it preserves B-Rep geometry with real edges and faces. STL and OBJ are mesh-only. glTF is for visualization. DXF is 2D only. Always export STEP if you need editable, machinable geometry.

I opened a STEP file from Zoo.dev in Fusion 360 last week and everything was where it should be. Selectable faces. Real edges. Fillets I could suppress or resize. Then I opened the STL version of the exact same part. Same geometry, supposedly. Fusion imported it as a mesh body, a lump of triangles I couldn't do anything useful with. I tried selecting a face to add a pocket and got 347 individual triangles highlighted like confetti. I closed the file, opened the STEP again, and got on with my life.

This happens constantly. People generate a part with a text-to-CAD tool, export whatever format the download button gives them, and discover ten minutes later that their geometry is either perfectly usable or essentially decorative. The format decides, and most people don't think about it until they're already staring at the problem.

Here's what actually comes out of text-to-CAD tools, what each format gives you, and which one you should be using. Spoiler: it's STEP. It's always STEP.

STEP: the one that matters#

STEP stands for Standard for the Exchange of Product Data. The specific flavors you'll encounter are AP203 and AP214, which differ in what metadata they carry, but for geometry purposes they're interchangeable. The file extension is .step or .stp, and every serious CAD program on earth reads them.

A STEP file contains B-Rep geometry. Boundary Representation. That means the file describes your part using mathematically exact surfaces, curves, edges, and vertices. A cylinder in a STEP file is a real cylinder defined by a center axis and a radius, not an approximation made of flat panels. A fillet is an actual tangent-continuous surface, not a strip of triangles pretending to be smooth.

This matters because B-Rep geometry is what CAD software works with natively. When you open a STEP file in Fusion 360 or SolidWorks, you get a solid body with selectable faces and edges. You can add features to it. Cut a pocket into that face. Chamfer that edge. Measure the distance between those two holes with actual precision. Dimension it on a drawing. Hand it to a CNC programmer who can generate toolpaths from the real surfaces instead of approximating over mesh data.

For a deeper look at why this distinction exists and why it shapes everything downstream, the B-Rep vs mesh post covers the geometry side in detail.

Zoo.dev outputs STEP by default, which is one of the reasons I keep coming back to it. The geometry comes from their KittyCAD kernel, which generates native B-Rep. The STEP file you get is not a conversion from some internal mesh. It's B-Rep all the way through, from generation to export. That's rare in the text-to-CAD space, and it's not a small thing.

The downsides of STEP are minor but real. The files are larger than mesh formats, usually by a factor of two to five for typical parts. They don't render in web browsers without a viewer library. They don't load in game engines or 3D printing slicers, though slicers can usually import them and tessellate internally. None of these are problems for engineering work. They're problems for demos and social media screenshots, which is why so many tools default to flashier formats.

STL: the format everyone knows and nobody should trust#

STL is the most common 3D file format in the world. Every 3D printer speaks it. Every CAD tool exports it. Every text-to-CAD tool offers it. It's been around since the 1980s, which in software terms makes it roughly Jurassic. And for engineering purposes, it's a dead end.

An STL file describes a shape as a collection of triangles. That's all it contains. No curves. No surfaces. No edges. No face information. No units (seriously, STL files don't specify whether the numbers are millimeters or inches). No color, no material, no assembly structure, no metadata of any kind. Just triangles.

A 50mm cylinder in an STL file isn't a cylinder. It's a polygon that looks like a cylinder if you use enough triangles. Select a "face" and you get a triangle. Measure an "edge" and you get a polyline approximation. Try to fillet something and your CAD software will tell you, politely or otherwise, that it can't fillet a mesh edge.

For 3D printing, STL works because the slicer only needs the outer shell to generate toolpaths. The triangulation artifacts are smaller than the printer's resolution, so the part comes out looking round even though the file says it's faceted. This is fine. Nobody cares about the mathematical purity of their prototype bracket's bore diameter at the file level when the printer adds its own inaccuracies anyway.

For everything else, STL is a trap. You can't edit it meaningfully. You can't add engineering features. You can't tolerance it. You can't generate a useful drawing from it. You can send it to a machine shop, but any machinist worth their hourly rate will ask you for a STEP file and silently judge you for sending the STL.

When a text-to-CAD tool only outputs STL, that tells you something about what's happening under the hood. It usually means the geometry was generated as a mesh internally, not as B-Rep, and the tool has no solid model to export. The STL isn't a simplified version of something better. It's all there is. The text-to-CAD vs text-to-3D distinction matters here: if the output is mesh-only, it's closer to text-to-3D regardless of what the marketing says.

OBJ: STL with slightly more ambition#

OBJ files are another mesh format, originally from Wavefront. They can carry vertex normals, texture coordinates, and material references, which makes them better than STL for rendering and visualization. In game development and visual effects, OBJ is a reasonable format. In engineering, it's another pile of triangles.

Some text-to-CAD tools offer OBJ alongside STL because it looks better in web-based 3D viewers. The normals help with smooth shading, so a cylinder actually looks smooth on screen instead of faceted. But the underlying geometry is still mesh. You still can't select a face. You still can't add features. You're still working with triangle soup.

I've seen people download OBJ files from text-to-CAD tools because the preview looked smoother than the STL preview, as if visual smoothness in a web viewer meant geometric quality in CAD. It doesn't. Smooth shading is a rendering trick. The mesh underneath is just as faceted as the STL version. Sometimes it's literally the same mesh with normals tacked on.

OBJ is fine if your next step is dropping the part into a rendering scene or a product visualization. It's not fine if your next step involves Fusion 360, a machine shop, or any tool that needs to know what a face is.

glTF: the visualization format#

glTF, sometimes called the "JPEG of 3D," is a format designed for efficient transmission and rendering of 3D scenes. It supports meshes, materials, textures, animations, and scene hierarchies. It's the format of choice for web-based 3D viewers, AR applications, and anywhere you need to display 3D content fast without a big download.

Zoo.dev offers glTF export, which is useful if you want to embed a generated part in a web page or hand it to someone who needs a 3D preview without installing CAD software. The format is lightweight and renders quickly in any browser with WebGL support.

For engineering? No. Same problem as OBJ and STL. It's a mesh format. No B-Rep. No selectable faces. No features. It's for looking at things, not working with them. I keep glTF around for client presentations where someone needs to rotate a part in their browser and feel involved. For actual work, it stays in the export menu.

DXF: the 2D one#

DXF is an Autodesk format that primarily handles 2D geometry. Lines, arcs, circles, polylines, text, dimensions. It's the lingua franca of laser cutting, CNC routing, and 2D drawing exchange. If you need a flat profile cut from sheet metal or a gasket outline sent to a waterjet shop, DXF is what you send.

Some text-to-CAD workflows touch DXF when you need to extract a cross-section or a flat pattern from a generated 3D part. It's not really a text-to-CAD output format in the same way STEP or STL are. It's more of a downstream artifact. You generate the 3D part, slice it or unfold it, and export the 2D profile as DXF.

DXF carries no 3D solid information. If someone hands you a DXF and says it's the output of a text-to-CAD tool, what they actually have is a 2D slice of a 3D part, or they're confused. Either way, ask for the STEP file.

The format hierarchy in practice#

Here's how I think about it, and how I'd recommend anyone using text-to-CAD tools think about it:

STEP first. Always. If the tool offers STEP export, use it. This is your working file, the one you open in CAD software, verify, edit, and send to manufacturing. It's the only format that preserves the geometry in a form that engineers can actually use. The text-to-CAD guide recommends this too, because there's no good reason not to.

STL for 3D printing. After you've verified the STEP file, export or convert to STL for your slicer. You can do this conversion in any CAD tool, or use a service API like Zoo's file conversion endpoint. The STL is a derivative product, not your source of truth.

glTF or OBJ for visualization. If you need a lightweight 3D preview for a web page, presentation, or client review, these formats work. They're display copies. Treat them that way.

DXF for 2D profiles. When you need a flat pattern, a cross-section, or a cutting profile, extract it from the STEP file and export as DXF. Don't try to go from text-to-CAD directly to DXF for a 3D part. The math doesn't work that way.

The format problem in the text-to-CAD market#

Here's what actually bothers me. Most text-to-CAD tools default to showing you a shiny 3D preview in a web viewer, which is a glTF or OBJ render. You see a smooth, attractive part. You feel good about the result. You click download and get an STL, because that's the format most closely related to what's on screen. The STEP option, if it exists, is buried in a dropdown or behind an extra click.

This is backwards. The STEP file is the valuable output. The mesh preview is a demo. But the UX is designed around the demo, because smooth rendered parts look better in screenshots than "your STEP file is ready for download" in plain text. Marketing wins. Engineering loses.

Zoo.dev is better about this than most. STEP is a first-class output. The UI doesn't try to hide it behind the mesh. But across the market, the norm is still mesh-first, STEP-maybe, which tells you something about who these tools are being built for and who they're not.

If a text-to-CAD tool doesn't offer STEP export, it's not a CAD tool. It's a shape generator. The text-to-CAD step file post goes into more detail on what to expect from STEP output specifically.

The conversion trap#

One more thing, because I've watched people fall into this and it always ends the same way. You cannot convert a mesh into a STEP file and get real B-Rep geometry. There are mesh-to-BREP tools. They exist. They try to fit surfaces over triangle data and produce something that has faces and edges. The results range from "usable for simple shapes" to "a fever dream with bad topology."

If the text-to-CAD tool generated mesh internally and gives you a STEP file, check whether that STEP file contains real B-Rep or a mesh body wrapped in a STEP container. Some tools do this. The file extension says STEP, but the contents are still triangles wearing a trench coat. Open it in your CAD software and try to select a face. If you get hundreds of tiny planar faces instead of a single surface, you've been had.

The B-Rep vs mesh post explains this distinction in more technical depth. The short version: B-Rep generated as B-Rep is good. Mesh converted to B-Rep is usually bad. The file format doesn't lie, but it can be dressed up to mislead.

Pick your format like you pick your fights#

Export STEP. Check the geometry. Use mesh derivatives for what mesh is good at, printing and previewing, and stop there. The file format is the first decision that determines whether your text-to-CAD output ends up in a real project or in a folder of curiosities you never open again. I've got both kinds of folders. The STEP folder gets opened. The STL-only folder collects dust. That tells you everything you need to know.

Newsletter

Get new TexoCAD thoughts in your inbox

New articles, product updates, and practical ideas on Text-to-CAD, AI CAD, and CAD workflows.

No spam. Unsubscribe anytime.