Convert STL between ASCII and binary

By arithmetic, not by the header text. A binary STL is an 80-byte header, a 4-byte triangle count, then exactly 50 bytes per triangle. If the file length equals 84 plus 50 times the declared count, it is binary. That test is used because an ASCII file cannot satisfy it by chance, while the header check most tools use is unreliable: a binary STL is legally allowed to begin with the word solid.

Because converting a file to the format it already is would be a silent no-op, so the to option has to be set explicitly to ascii or binary. If you pick the format the file already has, the tool says so, reporting that it was already that format with the triangle count, and hands back a re-serialised copy rather than pretending to have done a conversion.

The 80-byte header text and the per-triangle attribute bytes. A binary file's header often holds a slicer name or a comment, and the parser does not carry it over; the solid is named model instead. The 2-byte attribute field per triangle, which some tools use for colour, is not read and is written as zero when converting back. Vertex coordinates are also formatted to 6 significant digits in ASCII.

Because the parser found no facets. It looks for blocks matching facet normal, then outer loop, three vertex lines, then endloop and endfacet, and if none match it refuses: "no facet normal ... outer loop ... endloop endfacet blocks found", with a note that this is not a well-formed ASCII STL. A file that parses but contains zero triangles is refused separately as "parsed as a valid STL but contains zero triangles".

No, and that is why it exists. ASCII and binary STL are two encodings of the same triangle soup, so this is a direct parse and rewrite of the format itself, with no assimp and no WebAssembly involved. It also sidesteps the fact that the engine behind the other 3D tools here cannot export STL at all.

No. Every triangle is copied across with its stored normal and its three vertices exactly as they were read. Holes, flipped faces, duplicate vertices and wrong normals all survive the conversion unchanged. This changes how the mesh is stored, not what the mesh is.