ASCII STL stores every coordinate as a decimal string — vertex 1.2345678 0.0 -3.14159 — wrapped in facet normal / outer loop / endloop / endfacet boilerplate, seven lines per triangle. Binary STL packs the same triangle into exactly **50 bytes** of little-endian floats. The two formats are interchangeable for geometry but their on-disk footprints are not even close. This page is the version we wished existed when we were trying to figure out exactly *why* binary is smaller, what the byte layout actually looks like, what gets preserved by the conversion (and what gets silently rebuilt), and whether the result will load in Cura, PrusaSlicer, Bambu Studio, Blender, and Fusion 360. Drop a file above to convert it; everything below is the documentation.
solidDrop an ASCII STL file onto the tool. The first 80 bytes are sniffed for the literal solid token — and the size is checked against 84 + 50 × triCount to rule out a binary file that happens to start with solid.
three.js STLLoader parses every facet normal / outer loop / vertex triple in the file into a BufferGeometry.
The geometry is flattened to a non-indexed Float32Array so each triangle owns its own three vertex positions — exactly what the binary record format expects.
Each triangle is written as a 50-byte record (12-byte recomputed face normal + 36 bytes of vertices + a 2-byte attribute field) into a fresh ArrayBuffer of size 84 + 50 × triCount.
The file downloads as <original-name>.binary.stl. The page reports the percent reduction so you can see what you saved.
What the converter writes. Every offset is verifiable: open the output in xxd output.binary.stl | head and the bytes match this table. All multi-byte numeric fields are **little-endian**.
| Offset | Length | Field | Notes |
|---|---|---|---|
| 0 | 80 bytes | Header | ASCII text, zero-padded. Our writer fills the first 21 bytes with JAD Apps STL exporter; the remaining 59 bytes are 0x00. |
| 80 | 4 bytes | Triangle count | Unsigned 32-bit integer, little-endian. Caps the file at ~4.29 billion triangles. |
| 84 | 12 bytes | Triangle 0 — face normal | Three little-endian Float32s (nx, ny, nz). Recomputed from the vertices, not copied from the source. |
| 96 | 36 bytes | Triangle 0 — vertices | Nine little-endian Float32s in the order v0.xyz, v1.xyz, v2.xyz. |
| 132 | 2 bytes | Triangle 0 — attribute byte count | Unsigned 16-bit. Always 0x0000 in our output. Some non-standard tools repurpose this field for per-face colour. |
| 134 | 50 bytes | Triangle 1 | Identical layout. Records continue contiguously. |
| … | … | … | Total file size is exactly 84 + 50 × triCount bytes — the same equation we use to disambiguate ASCII vs binary on input. |
Binary cost is fixed. ASCII cost depends on how many digits each coordinate needs once JavaScript's default number-to-string formatter prints it. The numbers below assume typical short floats (1.234567 ≈ 8 chars); models full of long fractional coordinates skew toward 6×.
| Component | Binary | ASCII (typical) | ASCII (long floats) |
|---|---|---|---|
| Per-triangle bytes | **50** | ~200–220 | ~280–340 |
| Face normal | 12 (3 × Float32) | ~31 ( facet normal X Y Z\n) | ~52 |
| Three vertex lines | 36 (9 × Float32) | ~120 ( vertex X Y Z\n × 3) | ~210 |
| Loop / facet boilerplate | 0 | ~40 bytes of outer loop / endloop / endfacet | ~40 |
| Attribute slot | 2 (Uint16) | 0 | 0 |
| Whole-file overhead | 84 bytes (header + count) | ~25 bytes (solid name + endsolid name) | ~25 |
| Compression ratio | 1× | ~4× | ~6× |
Binary STL is the de-facto default across the FDM/SLA slicer ecosystem and every general-purpose 3D tool. Anything claiming STL support reads our output without fanfare.
| Tool | Reads binary STL? | Notes |
|---|---|---|
| Cura (UltiMaker) | Yes | Loads binary directly via Save / Open. ASCII works too but is much slower on large meshes. |
| PrusaSlicer / SuperSlicer | Yes | Default expectation. Prusa's exporter writes binary by default. |
| Bambu Studio / OrcaSlicer | Yes | Both bundle the same OpenCASCADE-derived STL importer; binary is the recommended input. |
| Blender (any version with the STL add-on) | Yes | Import → STL and Export → STL both default to binary. |
| Fusion 360 / SolidWorks / Onshape | Yes | All major MCAD packages import binary; SolidWorks exports binary by default. |
| Microsoft 3D Builder (Windows) | Yes | Built into Windows; reads binary and ASCII transparently. |
| MeshLab | Yes | Format toggle exposed on import/export. |
Three.js STLLoader (the parser this tool uses) | Yes | The same loader powers the import side here; the output is what we'd expect to feed straight back in. |
Common things to do *after* the conversion. The first example shows how to verify the output is well-formed without opening a 3D viewer.
Pipe the file through xxd (Linux, macOS, Git Bash) or Format-Hex (PowerShell). Bytes 0–79 (rows 1–5 of the dump) are the header — our 21-byte signature followed by 59 NUL bytes. Bytes 80–83 (the first four bytes of row 6) are the triangle count in little-endian. For a 12-triangle unit cube you'll see 0c 00 00 00 at exactly that offset.
$ xxd output.binary.stl | head -n 6 00000000: 4a41 4420 4170 7073 2053 544c 2065 7870 JAD Apps STL exp 00000010: 6f72 7465 7200 0000 0000 0000 0000 0000 orter........... 00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000050: 0c00 0000 0000 0000 0000 0000 0000 80bf ................
Binary STL has no padding and no variable-length fields, so (file_size - 84) / 50 must come out to a whole number equal to the triangle count baked at offset 80. If it doesn't, the file is corrupt or has trailing garbage.
# bash / git bash
FILE=output.binary.stl
SIZE=$(stat -c%s "$FILE")
TRIS=$(( (SIZE - 84) / 50 ))
echo "triangles per size: $TRIS"
echo "triangles per header: $(xxd -s 80 -l 4 -e "$FILE" | awk '{print strtonum("0x"$2)}')"Binary → ASCII → Binary should produce a file identical in triangle count and vertex coordinates. Header text and normals may differ (we rewrite both), but the geometry is bit-equivalent at Float32 precision.
# 1. Convert binary to ASCII to inspect: # use the STL Binary → ASCII tool on this site # 2. Convert the ASCII back here # 3. Compare triangle counts: xxd -s 80 -l 4 -e roundtrip.binary.stl xxd -s 80 -l 4 -e original.binary.stl
If you want to see what the converter saw before flattening it into binary, the STL Binary → ASCII Converter lets you reverse the trip. Useful for committing a geometry diff alongside the binary in a Git repo.
# Workflow: # build/ -> binary STLs (artefacts) # src/ -> ASCII STLs (committed) # CI step: ASCII -> binary on every push, # review step: binary -> ASCII for human diffs
Some CAD exporters (most notoriously older SolidWorks builds) wrote solid as the first five bytes of the 80-byte binary header. A naïve detector reading the first word would think the file is ASCII. The converter cross-checks: if file_size === 84 + 50 × triCount for the count it finds at offset 80, the file is treated as binary regardless of the header text — and the converter refuses with This file is already binary STL. Use the STL Binary → ASCII tool instead.
The STL spec allows multiple solids in one ASCII file, but binary STL has only one triangle list. STLLoader merges every solid into one BufferGeometry, so the binary output contains the union of all triangles. If you need to keep parts separate, split the source into one ASCII file per solid before converting.
Windows-saved ASCII STLs use \r\n. STLLoader parses both transparently — the conversion succeeds and the output binary is identical to the LF-source case. Our own ASCII writer always emits LF for compactness.
If two vertices coincide, the cross product (b - a) × (c - a) is the zero vector. The converter writes (0, 0, 0) for that face's normal. Most slicers tolerate this on load but may flag it as a non-manifold or zero-area face. Run the STL Repair tool afterwards if your slicer complains.
Many ASCII exporters write a facet normal value that doesn't actually equal the cross product of the triangle's vertices. The converter ignores the source normal entirely and recomputes a fresh face normal from the vertex positions on the way out. If the source had flipped winding, the new normal will point in the opposite direction — but the geometry itself is preserved.
ASCII STLs are large (often 40+ MB for a model whose binary equivalent is under 10 MB), so it's common to bump into the free 25 MB cap. The upload is rejected client-side before parsing — no partial work runs. Pro covers files up to 250 MB; Developer up to 2 GB, which is enough for the largest practical ASCII STLs.
Detection looks at the first 80 bytes, not the extension. A file that doesn't start with solid and isn't sized as a valid binary STL produces a parse error from STLLoader with the message *Unsupported file format*. Use the STL to OBJ or GLB to OBJ tools as appropriate.
STLLoader's tokenizer accepts scientific notation. The output binary writes a plain Float32 — the exponent disappears because the binary format has no concept of a notation. The numeric value is preserved at full Float32 precision (~7 significant decimal digits).
0 bytes uploaded. STL ASCII → Binary Converter runs entirely in your browser using three.js and WebGL. Your meshes never leave your device.
Geometry is bit-identical at Float32 precision — every vertex coordinate the source held is written into the binary output with no rounding. The face normal *value* is replaced (we recompute it from the vertices rather than trust the source), but the geometry it describes is unchanged. Per-face colour, if encoded by a non-standard exporter into the 2-byte attribute field, is dropped — we always write 0x0000.
Many ASCII exporters write a normal that doesn't match the triangle's vertex order — common when an editor flipped a face but its exporter copied the stored normal verbatim. Recomputing (b - a) × (c - a) and normalising guarantees that every face's stored normal agrees with the right-hand rule applied to its vertex winding. If your source had wrong-direction normals deliberately, the output will not preserve them.
Yes. The compatibility table above lists the slicers we explicitly verified. The output is a textbook binary STL: 80-byte header, 4-byte little-endian triangle count, 50-byte records, attribute byte count of 0x0000. Anything that claims to read STL — and that's effectively every slicer and CAD package in the FDM/SLA ecosystem — reads this format.
Our writer fills the first 21 bytes with the ASCII text JAD Apps STL exporter and pads the remaining 59 bytes with 0x00. The STL spec leaves the header content up to the exporter — some tools embed timestamps, author IDs, or even a copyright string. The 80-byte header **must not** start with the word solid, because doing so makes the file look ASCII to naïve parsers. Ours doesn't.
An ASCII triangle is roughly seven lines of text totalling ~200–340 bytes (depending on how many decimal digits each coordinate needs). A binary triangle is exactly 50 bytes — three Float32 normals (12 bytes), nine Float32 vertex coordinates (36 bytes), and a 2-byte attribute slot. Floats stored as text expand by the digit count; floats stored as raw bytes don't.
No. It's a pure format converter — every triangle in the source ends up in the output, including degenerate triangles (zero area), non-manifold edges, and intersecting faces. If you need a clean watertight mesh for 3D printing, run the STL Repair tool afterwards.
Strictly 32-bit — that's all the binary STL format supports. ASCII STL has no precision requirement so some exporters write 17-digit doubles, but those get truncated to single-precision (~7 significant decimal digits) when they hit the binary writer. For physically large objects with sub-micron features, this can be lossy — but every other STL tool has the same limit.
Not for geometry — STL is unordered, slicers don't care. But the converter preserves input order: triangle N in the source becomes record N in the output. If your pipeline depends on order (custom inspection scripts, layer-by-layer comparison), the round-trip is stable.
The Developer tier accepts files up to 2 GB. Above that we'd recommend converting on the command line — python -c "import trimesh; m = trimesh.load('huge.stl'); m.export('huge.binary.stl')" does the same job natively. The browser is bounded by available RAM (typically 4× the file size during parsing); the size caps reflect what tested reliably.
The name from the solid <name> line at the top of the ASCII source is not preserved in the binary header — binary STL has no dedicated name field, only the freeform 80-byte header (which we always fill with our exporter signature). If the original name was load-bearing, store it alongside the binary or use a richer format like GLB or 3MF.
STL stores no vertex-sharing information. Every triangle gets its own three vertex positions even when two triangles share an edge. An ASCII file with 12 triangles always converts to a binary file with 36 vertex positions on disk, even if the mesh has only 8 distinct vertex locations. Use the STL to OBJ or STL to GLB tools if you want a format that deduplicates shared vertices.
No. The converter runs entirely in your browser via three.js — vertex data, header text, and the binary output blob never leave the page. When signed in, the dashboard records an anonymous tool_run event with the file size and a download event on save; neither carries any of the file's contents. You can verify this in the DevTools Network tab: the only fetch during conversion is the event endpoint, with a JSON body of ~100 bytes.
Convert binary STL to human-readable ASCII STL for version control, semantic diffs, and debugging. Full output spec, line-by-line. Free, browser-based, no upload.
Open toolReveal the 80-byte STL header, GLB JSON chunk, software origin, vertex/face stats, and authoring tool from any 3D file. Browser-based, zero upload.
Open toolConvert STL files to GLB (binary glTF) directly in your browser. Smaller, faster, and AR-ready. Zero upload — your meshes never leave your device.
Open toolConvert STL meshes to Wavefront OBJ in your browser. Open the result in Blender, Maya, Cinema 4D, or any 3D tool. Privacy-first — zero upload.
Open tool