cadtomesh

IGES → STL

Converting IGES entities into binary STL facets

An IGES file stores neutral CAD geometry as flat, entity-based 80-column ASCII records, including type 128 rational B-spline surfaces and type 144 trimmed surfaces. Converting it to STL tessellates those surfaces into triangles at a chosen deflection, welds the result into one mesh, and writes binary facets. Units, colour definitions and surface names do not survive.

Drop a .iges file here, or

Processed on this device ยท nothing uploaded

16input formats
7output formats
0 Buploaded, ever

How to convert IGES to STL

  1. Load the IGES fileOpen a .iges or .igs file and let the reader walk its fixed-width ASCII records. The parser steps through the Start, Global, Directory, Parameter and Terminate sections to recover every entity and its numeric payload.
  2. Pick a deflection levelChoose Draft, Standard, Fine or Max. This value sets the chord tolerance the OpenCascade WebAssembly kernel applies when it approximates curved B-spline patches with flat triangles; tighter tolerances yield denser facet coverage.
  3. Tessellate the surfacesThe kernel turns type 126 curves and type 128 surfaces, along with type 144 trimmed surfaces and their type 142 boundary curves, into triangle sets. Wireframe-only type 110 lines contribute no facets.
  4. Flatten and weldAll triangle sets are merged into one BufferGeometry that carries only position and normal attributes. A weld keyed on both coordinate and normal values builds an index buffer while the facet count stays under 300,000; above that limit the mesh is expanded with no index at all.
  5. Emit binary STL facetsEach triangle becomes a 50-byte record holding a facet normal, three vertices and an unused 16-bit attribute field, preceded by an 80-byte header and a 32-bit facet count.
  6. Save the .stl fileThe finished byte stream is handed back as a downloadable STL file. Slicing tools conventionally read its bare coordinate numbers as millimetres because the output declares no unit.

What happens when IGES is converted to STL

How an IGES file is laid out

An IGES stream is plain ASCII split into fixed 80-character records, a convention inherited from the 1980s punch-card era of the Initial Graphics Exchange Specification. Version 5.3 is the last published revision. Five labelled sections appear in order: Start holds human-readable comments, Global stores delimiters and unit flags, Directory indexes every entity with a fixed field layout, Parameter carries the numeric payload, and Terminate closes the file with record counts. Each line dedicates columns 73 to 80 to a sequence number, so identifiers in the first 72 columns drive parsing. Because the format is flat, entities reference one another through pointers rather than a nested assembly tree. The reader reconstructs these links before any geometry is generated, which is why a malformed Directory entry can orphan a surface entirely.

Which entity types carry the geometry

The Parameter section is a catalogue of numbered entity types, and only a subset produces surface geometry. Type 110 is a straight line, type 126 a rational B-spline curve, and type 128 a rational B-spline surface defined by knots, weights and a control net. Type 144 wraps a surface with a trimmed parametric boundary, while type 142 stores the curves that lie on that surface and define trimming loops. Type 314 assigns colour and type 406 supplies form or property data such as names and layers. The converter feeds curve and surface entities to the tessellator, treats trim loops as boundary constraints, and ignores presentation-only records. A file built mostly from 110 lines therefore yields little or no solid surface to facet.

Why topology is unreliable in IGES

IGES was designed to exchange wireframe and surface descriptions, not watertight solids, so there is no guarantee that faces are stitched into a closed shell. Exporters frequently emit duplicate surfaces, untrimmed patches that overlap their neighbours, or geometry that was never joined along shared edges. The converter does not attempt to sew these patches into a manifold solid; it tessellates each surface independently. Coincident patches become coincident triangles, open edges remain open, and interior faces are retained rather than removed. STL has no concept of a solid, a shell, or an orientation flag, so these defects are simply carried into the facet list. The user should expect the .stl to describe a surface soup whose watertightness depends entirely on how clean the originating CAD model was.

Tessellation with four deflection settings

Curved surfaces cannot be written directly into STL, which understands only planar triangles. The WebAssembly build of OpenCascade approximates each B-spline or trimmed patch by sampling it against a chord-error tolerance. Four presets control that tolerance: Draft uses the loosest value and the fewest triangles, Standard balances density, Fine tightens the deviation, and Max pushes it further for smooth curvature. A smaller deflection increases the facet count roughly in step with surface curvature, so a filleted bracket can grow far denser than a flat plate of the same size. Normals are generated per facet from the triangulated geometry. The setting is applied uniformly to every surface in the file because the flattened output has no per-face material or grouping to vary it.

Flattening into a single geometry

Before anything is written, every triangle produced by the kernel is merged into one BufferGeometry whose channels are limited to positions and normals. There is no colour array, no UV set, no group list and no material slot, regardless of how many entities the IGES file contained. When the triangle count is under 300,000, the builder welds vertices keyed on both position and normal, producing an indexed buffer that shares corners between adjacent facets. Larger shells skip that step and are expanded without an index buffer, so each triangle keeps its own three corners. This single flat mesh is the only structure the STL writer sees; entity boundaries, layer names and assembly structure have already disappeared by this stage.

The binary STL facet record

Each exported triangle is packed into a fixed 50-byte record. A leading 80-byte header has no required meaning, and a 32-bit unsigned integer right after it states how many facets follow. Twelve 32-bit floats inside every record hold the facet normal and the three corner triples; a trailing 16-bit attribute short stays at zero. Coordinates pass straight through from the BufferGeometry without scaling because no unit is declared. The normal is written even though many readers recompute it from winding. Constant record length makes the byte total 84 plus 50 multiplied by the triangle count and permits purely sequential streaming, so the writer never needs to seek backwards or scan for delimiters.

What disappears on the way out

Several classes of information have no destination in STL. The unit flag from the Global section is dropped, colour defined by type 314 entities is discarded, and type 406 property records such as names, layers and forms are ignored. Trimming curves of type 142 survive only as the polyline edges of facets, never as exact analytic boundaries, and entity or assembly hierarchy is flattened into one undifferentiated mesh. Slicing tools conventionally read the resulting bare coordinates as millimetres, so a model authored in inches will appear one twenty-fifth of its intended size unless it was rescaled before conversion. No colour, material, texture or metadata channel exists to carry any of these attributes forward.

IGES vs STL

IGES sourceBinary STL facets
StructureFlat entity directory across five ASCII sectionsFlat list of triangle facets
GeometryRational B-spline curves (126) and surfaces (128)Triangulated facet soup
Record formatFixed 80-column ASCII textBinary 50-byte facet records
Unit declarationDeclared in the Global sectionNone; coordinates are unitless numbers
ColourType 314 colour entitiesNo colour channel
TopologyEntity pointers, no solid guaranteeOne flattened mesh, no shells or groups
TrimmingType 142 curves and type 144 trimmed surfacesApproximated as polygon facet edges
Surface normalsImplicit in parametric surfacesOne normal vector per facet
Sections / headerStart, Global, Directory, Parameter, Terminate80-byte header plus 32-bit facet count
Vertex sharingNot applicable; entities stay independentNone; every facet repeats its three corners

Supported formats

FormatReadWriteNotes
STEP (.step .stp)Yes–ISO 10303 B-rep, AP203 / AP214 / AP242
IGES (.iges .igs)Yes–Entity-based surfaces, up to 5.3
BREP (.brep)Yes–OpenCascade native B-rep
STL (.stl)YesYesBinary and ASCII triangles, no units
OBJ (.obj)YesYesv / vn / f records; .mtl references ignored
PLY (.ply)YesYesBinary position and normal arrays
GLB / glTF (.glb .gltf)YesYesglTF 2.0, binary or JSON with data URI
3MF (.3mf)YesYesOPC/ZIP package, declares millimetres
FBX (.fbx)Yes–Binary and ASCII, static mesh only
DAE (.dae)Yes–Collada scene graph is flattened
3DS (.3ds)Yes–Legacy chunk-based 3D Studio format
AMF (.amf)Yes–XML, ZIP-compressed packages supported
USDZ (.usdz)YesYesZIP containing a USD stage

Known limitations and why a conversion can fail

Open and overlapping shells stay open

Because the input offers no solid-topology guarantee, the STL output can contain gaps, T-junctions and coincident triangles where duplicate or unstitched surfaces met. The converter tessellates patches individually and never sews edges, so a shell that was already open in the IGES file remains open after faceting. STL provides no flag to mark a closed volume, no normal-consistency requirement across neighbouring facets, and no repair pass. Downstream tools that need watertight meshes may therefore report non-manifold edges. Choosing a finer deflection does not fix topology; it only adds more triangles along the same broken boundaries. Inspecting the source CAD model for untrimmed patches before conversion is the only reliable remedy, since this stage preserves geometry rather than healing it.

Unit declarations are lost

The Global section of an IGES file can state whether coordinates mean millimetres, inches or another measure, but STL has no field in which to record that choice. The writer copies numeric coordinates verbatim and discards the unit flag. A part drawn as 2 inches wide is written as the number 2.0, and a slicer that assumes millimetres will treat it as two millimetres. Neither binary nor ASCII STL can carry a scale, so any correction must happen before conversion or by scaling the exported mesh afterwards. The flattened BufferGeometry holds pure floats with no metadata attached, which is exactly why the unit context cannot be reconstructed from the .stl alone.

Colour, layers and names are dropped

Type 314 colour entities, type 406 form and property records, layer assignments and any descriptive labels have no counterpart in the target format. Binary STL facets contain only a normal, three corners and an unused attribute short; there is no palette, no per-face colour and no text field. The exporter emits a single mesh with no material slots, so even if a source surface was coloured red and its neighbour blue, both become indistinguishable grey triangles. Nothing in the pipeline attempts to bake appearance into vertex data, because the flattened geometry deliberately keeps only position and normal attributes. Users needing colour should choose a different output format, since this pair is strictly geometric.

Deflection changes size, not correctness

Draft, Standard, Fine and Max are chord-tolerance presets, not accuracy guarantees about the finished part. A loose setting can visibly flatten a tight radius or leave a polygon silhouette on a cylinder, while Max can multiply the facet count on a heavily filleted model and make the .stl large and slow to slice. The tolerance is applied globally, so a file mixing broad planar faces with small curved details cannot be tuned per surface. Faceting also replaces analytic trim loops with polyline approximations, so tiny holes or narrow slots may close or distort at a coarse setting. There is no adaptive refinement and no post-tessellation repair, meaning the chosen level is the only control over how closely triangles follow the original B-spline surfaces.

Wireframe input yields empty facets

Some IGES files describe geometry exclusively with type 110 lines and type 126 curves, offering no surface at all. Since tessellation operates on surfaces, these records generate zero triangles and the resulting STL contains a facet count of zero. The kernel cannot invent a solid from an open wireframe, and the converter does not attempt lofting, skinning or face reconstruction. A model that looked correct as a wire drawing in its authoring system can therefore produce an empty or nearly empty mesh. Checking that the Directory section contains type 128 or type 144 surface entities before converting avoids this surprise. Curves that only serve as trim boundaries for type 144 surfaces are likewise not exported as standalone edges.

Trimmed boundaries become polygon edges

A type 144 trimmed surface pairs a type 128 underlying patch with type 142 curves on that surface which mark the visible region. During tessellation the trim region is sampled alongside the surface, and its boundary emerges as a chain of straight facet edges rather than the exact analytic curve. Sharp corners, small circular holes and narrow slits are the most sensitive to this approximation: at a coarse deflection a hole can shrink, skew or vanish. The flattened mesh has no record that an edge was once a trimming curve, and STL offers no way to tag it as such. Increasing the deflection level reduces the deviation but never restores the original curve, because the output format is fundamentally a triangle list.

Frequently asked questions

Why does my IGES file produce so many triangles?

Each curved type 128 surface and each type 144 trimmed patch is approximated by flat triangles, and the chosen deflection sets how tightly those triangles follow the curvature. Fine and Max tighten the chord tolerance, which multiplies facet counts on fillets, holes and cylindrical faces. Duplicate or overlapping surfaces in the source are tessellated independently rather than merged, so they add triangles too. Switching to Draft or Standard reduces the count, but it cannot remove facets that come from redundant geometry in the IGES file itself.

Does the STL keep the colours defined with type 314 entities?

Colour does not survive. Binary STL facets store a normal, three corner coordinates and a 16-bit attribute field that carries no colour in this export. Type 314 colour definitions, along with type 406 property records, are ignored by the writer because the flattened geometry holds only position and normal attributes. Every surface, whatever its original shade, becomes an indistinguishable triangle. If appearance matters, choose an output format that has a colour channel instead of this geometric-only pair.

Does the IGES unit flag survive into the STL?

The flag is dropped. The Global section of an IGES file can name millimetres or inches, but the writer copies numeric coordinates verbatim and drops that flag. Slicers conventionally read the bare numbers as millimetres, so a part authored in inches is interpreted roughly twenty-five times too small. Neither binary nor ASCII STL carries a scale field, so any correction must happen before conversion or by scaling the exported mesh afterwards.

Why is the resulting mesh not watertight?

IGES offers no solid-topology guarantee, and many files contain duplicate, untrimmed or unstitched surfaces. The converter tessellates each patch on its own and never sews shared edges into a closed shell, so gaps, T-junctions and coincident triangles survive into the facet list. STL itself has no flag for a closed volume and performs no repair. A finer deflection only adds triangles along the same boundaries; cleaning the source CAD surfaces is what actually fixes the leaks.

What happens to wireframe-only IGES drawings?

A file built only from type 110 lines and type 126 curves contains no surface for the kernel to tessellate. Since STL is a triangle list, such a drawing yields a facet count of zero and an effectively empty mesh. The converter does not loft or skin wires into faces, and it cannot reconstruct a solid from an open wireframe. Confirm that the Directory section lists type 128 or type 144 surface entities before expecting a usable .stl output.

Can I tune deflection per individual surface?

Per-surface tuning is not available. The four presets are applied uniformly across the whole file. Before export, all tessellated patches are merged into one BufferGeometry with no groups, no materials and no per-face tags, so there is nothing left to distinguish one surface from another. A single chord tolerance drives the kernel for every entity at once. If a model mixes large flat faces with tiny fillets, the only option is to choose a global level that balances silhouette quality against the resulting triangle count.

How are trimming curves of type 142 handled?

Type 142 curves on a surface mark the visible boundary of a type 144 trimmed patch. During tessellation that region is sampled together with the underlying type 128 surface, and the boundary is emitted as a chain of straight facet edges. It is no longer an exact analytic curve, and STL cannot label an edge as a trim. Small holes and narrow slits are the features most prone to distortion at a coarse deflection, because their outlines are approximated by relatively few segments.

Does this pair emit binary facets or text lines?

This pair produces the compact binary form. Its structure is an 80-byte lead-in, an unsigned 32-bit facet total, then one 50-byte record per triangle containing a normal, three corners and an unused attribute short. The alternative ASCII spelling would describe the same geometry with facet normal, outer loop and vertex keywords and occupies noticeably more bytes. Fixed record width is the reason binary is chosen here, since the whole stream can be emitted sequentially without searching for delimiters.

Related converters

All converters

Last updated: