Convert STL between ASCII and binary
Convert an STL 3D model between its ASCII (text) and binary encodings. Both describe the same triangle mesh, so this is a direct parse-and-rewrite with no 3D engine involved. Nothing is uploaded.
Runs on your device. The file is never uploaded.
Convert STL between ASCII and binary decides what you handed it by arithmetic, not by the leading word solid. A binary file measures 84 bytes plus exactly 50 per triangle, and the to option has no default, so the direction is yours. Header text and the 2-byte attribute field per triangle are dropped, and normals are copied, never recomputed.
Questions
How does it know whether my STL is already 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.
Why is there no default direction?
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.
What gets lost when I convert binary to ASCII?
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.
Why was my ASCII file rejected?
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".
Does it need a 3D engine?
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.
Will it repair a broken mesh or recalculate normals?
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.