Is a converter's format list a promise or a catalogue — when the hub page omits a format its own leaf page serves?

A format list is a catalogue of what has been wired up, not a promise that a pairing produces a usable file. Two lists on the same site are built by different machinery and they disagree: on the first sample the hub page that enumerates CAD formats does not contain STEP, while a working STEP page sits one level below it on the same domain — so the hub is a routing index, and a format’s absence from it says nothing about whether the site converts it. On the second sample the hub enumerates every input one by one and its STEP page offers a much shorter list of outputs, grouped into model, image, video and archive. A promise can only be checked on the artefact: its extension and its length. Here there is one direction — four extension spellings, two formats, one output — and the 10 mm cube still lands at 12 triangles and 684 bytes, where 684 = 84 + 50 × 12.

This page answers one question: whether the format table a converter prints can be read as a promise. Both samples were read on 1 November 2026, again on the same day before release, and are described by structure only — no name, no count and no sentence from them is reproduced here. The right-hand side is this site’s own output, re-run by this project’s test suite before release.

Two lists, one site

The first sample sells conversion across a wide catalogue, and its CAD hub page is a table: one row per format, one link per row, each row pointing at that format’s own page. STEP is not one of those rows. It is, however, reachable one step further in: the site keeps a live page for STEP with a full list of output targets on it, and that page is served from the same domain as the hub that omits it.

That single missing row is enough to settle the reading. If the hub were a coverage list, a format with a live page under it could not be absent. So the hub is assembled from something narrower than the site it belongs to — most plausibly a directory of slugs and descriptions that was last rebuilt before that format’s page went up. The leaf page, by contrast, is written around one pipeline: it knows its own inputs and its own output targets because they are the thing it runs.

The consequence for a reader is the point of this page: a format that is missing from a hub is not evidence that it cannot be converted, and a format that is present is not evidence that a given pairing works. Only the second of those has a test you can run, and it is not on the table.

The hub is a directory; the leaf is a pipeline. The hub page leaves out a format whose own conversion page is live one level below it, so the hub cannot be read as coverage — and the leaf’s four output groups are wider than anything a CAD viewer produces.

A row against its own paragraph

The same leaf page carries a second disagreement, this time inside one screen. Its information table gives the format a type and a storage label, and the label says binary. A few lines further down, the description of that same format says the files are text-based and explains why they grow large. Two sentences about one format, printed by one page, pointing opposite ways.

This is not a subtlety to be forgiven; it is what a catalogue entry looks like when it is copied from a directory rather than read off the pipeline. The table row is metadata — a short string that some earlier build recorded. The description is prose written by whoever wrote the page. Neither is derived from the file in front of you, and neither is maintained by the code that converts.

So the label cannot be used as a fact either. What settles whether a STEP file is text or binary is the file: STEP is text, and its length is a consequence of that; STL can be either, and the binary form has a fixed shape — an 84-byte header and 50 bytes per triangle. That is the only place where a format claim becomes arithmetic.

Binary in the table, text in the paragraph. One leaf page describes one format two opposite ways, which is exactly what happens when a label is copied from a directory and the prose is written separately; the remedy is to read the file, not the row.

Inputs on the hub, outputs on the leaf

The second sample disagrees in a different direction, and the disagreement is in the shape of the two lists rather than in a single row. Its hub page enumerates the formats you can bring in, one card per input. Its STEP page then lists what that input can become: model formats first, then image, video and archive targets. The output list is much shorter than the input list, and four of its groups are not model formats at all.

Read together, the two lists answer two different questions. The hub answers “what can I bring in”, the leaf answers “what can I get out”, and neither answers the one a reader actually has: will this pair produce geometry that survives to a slicer. A raster or a video target is a property of a renderer bolted onto a conversion pipeline; it proves the pipeline can draw a picture of the model, not that it can hand you a mesh.

That is why a wide table reads as capability and behaves as inventory. The count is real, the wiring behind each cell is not shown, and the cells are not equal in what they deliver — which is a fact about the catalogue, and not a criticism of the catalogue.

Where a promise can be checked

A promise, as opposed to a listing, has a test. On a converter that test lives in the output file, and it has two halves: the extension and the length. The extension says the container; the length says how much geometry is inside, because binary STL spends a fixed 84 bytes on its header and 50 bytes on every triangle, nothing else.

What each side of a format claim can be checked against
Claim	Where it is written	What can check it
“We accept this format”	a hub row or a feature table	the format’s own page, and a file that parsed
“We write that format”	an output list	the downloaded file’s extension
“This pair works”	usually nowhere	a converted file whose byte count matches its triangle count
“This is binary” or “this is text”	a row, or a paragraph	the file’s own bytes

The third row is the one every table leaves out. (bytes − 84) ÷ 50 is the whole test: 684 bytes returns 12 triangles, and 368,684 bytes returns 7,372, with no rounding in either direction. A converter that prints a pair and hands you a file matching that arithmetic has kept a promise; a converter that prints a wider table and hands you nothing you can weigh has only published a catalogue.

One direction, counted

This site’s own list is short enough to be checked in full, which is the only reason it can be printed here as a promise. The input family is two formats — STEP and IGES — spelled four ways: STEP, STP, IGES, IGS. The output family is one: binary STL. The 10 mm cube is 12 triangles and 684 bytes at Draft, Normal and Fine, and the 18-part assembly leaves as 7,372 triangles and 368,684 bytes at Normal from a 433,606-byte input, where 368,684 = 84 + 50 × 7,372.

Two facts make that list a different kind of document from the tables above. There is no hub page standing in front of it: the converter is one page, so there is no second list that could drift out of step with the first. And the single list is published in one place only, the format section of the verification page, which is the site’s only authority on what comes in and what goes out — other pages point at it instead of re-printing it.

Four spellings, two formats, one output, and one sum. The input family spells two formats four ways and the output family is one container; the only check that is independent of the page is the byte count, which returns the triangle count exactly in both worked examples.

What you can check in a minute

Compare a hub against its leaf. Pick one format from the hub and open its page; then search the hub for a format you know the site converts. If the hub is missing something its own leaf serves, the hub is a directory and its count is not coverage.
Read the label row against the description. A table field and a paragraph on the same page can disagree about the same format. When they do, both are stale copies of something else, and the file is the tie-breaker.
Count what the output list actually contains. Image, video and archive targets sit beside model targets in one list even though they deliver different kinds of thing. A wide output list is inventory, not fidelity.
Weigh the file you got. (bytes − 84) ÷ 50 returns the triangle count exactly: 684 bytes returns 12, 368,684 bytes returns 7,372. This is the only line on this page that a stranger can run without trusting anybody.

Questions this page answers

Is the format table on a converter page a promise?

No. On the first sample the hub list of CAD formats does not contain STEP at all, while a working page for STEP sits one level below it on the same domain, so the hub is a routing index rather than a coverage list and a format’s absence from it says nothing about whether the site converts it. On the second sample the hub enumerates every input format one by one, and its STEP page offers a much shorter list of outputs grouped into model, image, video and archive. A reader who wants a promise has to look at the artefact, not at the table.

Why do two format lists on the same site disagree?

Because they are produced by different machinery. A hub page is assembled from a directory of slugs and descriptions, while a leaf page is written around one pipeline that actually runs. When a format is added to the pipeline the leaf page can go live while the hub is still the older build, so the same site prints two answers to the same question, and neither of them is a truthful count of what works. This page treats the disagreement as evidence about the table, not about the format.

What can I check on a converter page instead of trusting its table?

Two things on the output file: its extension and its length. Binary STL is an 84-byte header plus 50 bytes per triangle, so (bytes − 84) ÷ 50 returns the triangle count exactly: 684 bytes returns 12, and 368,684 bytes returns 7,372. A table can promise a pair of formats; a file with the right count is the promise kept. On this site the path is four extension spellings, two formats and one output, and the 10 mm cube lands at 12 triangles and 684 bytes at every setting.

Where these numbers come from

Published 2026-11-01 · Last updated 2026-11-01

Hub page without the format its own leaf page serves — a structural reading of two pages on one site, taken on 1 November 2026 and again on 1 November 2026 before publication; the page is described by what it offers, not by name, and no count from its tables is printed here.
One table row labelling binary against a description calling the same format text-based — the same dated reading; the contradiction is quoted as a structure, not as wording.
Hub counting inputs while the leaf counts outputs, in four groups — a second site, read on 1 November 2026; the four groups are named because the grouping is the point, and the number of targets in each is not printed.
12 triangles / 684 bytes for the 10 mm cube — this project’s own output for cube-10x10.stp at Draft, Normal and Fine, re-run by npm test.
433,606 bytes in, 7,372 triangles and 368,684 bytes out — the 18-part AP214 assembly as1-oc-214.stp at Normal, with the length asserted against 84 + 50 × 7,372.
What this page does not print — no format count from any other converter’s table, no capacity figure, no monthly search volume, no keyword bid, no competitor name. Large assemblies are unverified.

npm test

The command above re-runs every number on this page. These are this page’s own test files and own settings, not a CAD standard. The step page owns where in the pipeline the format actually changes, the format-pairs page owns the year a converter sold pairs one at a time, and the pipeline page owns what happens between upload and download.