Does the STEP flavour change the STL output?

Not on its own. This site's two test assemblies do produce different counts at the same preset — 6,088 triangles for the AP203 file against 7,372 for the AP214 file at Normal, a gap of 21.1% — but the header of each file names a different exporter, and the exporter decides how the exact surfaces are written down, which is what tessellation samples. The mesh answers to the quality setting, not to the protocol number, so neither flavour promises a better or worse result.

How do I tell which flavour my STEP file is?

Open the file in a text editor and read the FILE_SCHEMA line in the header, a few lines down from the top. The two test files used on this page show both spellings: the AP203 file spells the whole protocol name out, and the AP214 file gives the schema name AUTOMOTIVE_DESIGN with a numeric tag whose 214 is the protocol number. STEP is plain text, so no tool is needed to read it.

Which flavour should I choose when exporting a STEP file for STL?

Whichever your CAD tool offers — both convert, and this engine reads both through the same reader. The decision that changes the mesh is the quality setting, not the protocol: flat faces cost exactly 12 triangles at every setting, and curved faces are where the tiers separate. After converting, the byte size confirms what you got, because a binary STL is 84 bytes of header plus 50 bytes per triangle.

What do AP203 and AP214 mean on a STEP file? Two flavours, one STL

Q: What do AP203 and AP214 mean on a STEP file?

They name the application protocol the file was written against, and the name sits in the FILE_SCHEMA line near the top of the file. AP203 is the configuration-controlled 3D design protocol for mechanical parts and assemblies; AP214 is the automotive design protocol, which carries colour and material assignment on top of the same solid geometry. For STL the flavour changes nothing in the pipeline: the same reader takes both, tessellation runs the same way, and whatever AP214 adds beyond geometry is dropped on the way to the mesh.

The header of every STEP file names the protocol it was written against, and the two names that come up most often are AP203 and AP214. This page reads those two lines out of this site's own test files, converts both files at all three presets, and separates what the flavour decides from what it does not. Every number was measured on the machine that wrote this page and re-run by npm test before publication.

The short answer

For STL, the flavour is not a variable: both AP203 and AP214 go through the same reader and the same tessellation, and whatever AP214 adds beyond geometry is dropped on the way to the mesh. The two names are the file header's way of recording which application protocol the file was written against — AP203 for configuration-controlled 3D design of mechanical parts and assemblies, AP214 for automotive design, which carries colour and material assignment on top of the same solid geometry. Neither one describes a mesh, and neither one tunes one. The two test assemblies this site converts everywhere do land on different triangle counts at the same preset — 6,088 triangles for the AP203 file against 7,372 for the AP214 file at Normal — but the header of each file names a different exporter, and it is the exporter's way of writing the exact surfaces, not the protocol number, that the tessellation samples. Pick the quality setting by curvature, convert, then confirm what you got from the byte count: a binary STL is 84 bytes of header plus 50 bytes per triangle, so (size − 84) ÷ 50 is the count, whichever flavour went in.

A STEP file is plain text under the ISO 10303-21 standard, and its header is a short block in the first lines. The flavour line is the one that starts with FILE_SCHEMA. This site's two test assemblies — the public NIST AS1 conformance models — carry one flavour each, and both spellings are real:

FILE_SCHEMA(('AP203_CONFIGURATION_CONTROLLED_3D_DESIGN_OF_MECHANICAL_PARTS_AND_ASSEMBLIES_MIM_LF'));

FILE_SCHEMA(('AUTOMOTIVE_DESIGN { 1 0 10303 214 1 1 1 1 }'));

The first, from as1_pe_203.stp, spells the whole protocol name out. The second, from as1-oc-214.stp, gives the schema's name — AUTOMOTIVE_DESIGN — followed by a numeric tag in which the 214 is the protocol number. One header, two spellings, both read the same way. If a file you were handed mentions neither name, it was written against some other protocol; the header will say which.

What the two protocols are

Both are parts of ISO 10303, the STEP standard. AP203 covers configuration-controlled 3D design of mechanical parts and assemblies, and it is the older, geometry-focused protocol. AP214 covers automotive design and carries the same solid geometry plus colour and material assignments on top. What both have in common matters more for conversion: they describe exact surfaces — planes, cylinders, splines — rather than triangles, which is the difference between STEP and STL in the first place. When the mesh is produced, the extra colour and material data an AP214 file carries has nowhere to go, and it is dropped — the verification page's colour check shows the drop on a measured pair of files.

Same reader, same tessellation: the measured pair

Both test assemblies are 18-part models, and both go through this engine at all three shipped presets. The counts land where the exporter's writing puts them, not where the flavour suggests:

Triangle counts and binary STL sizes measured with this engine in Node.js; `npm test` re-runs every cell and re-checks every byte figure against 84 + 50 × triangles.
File	Flavour	Draft	Normal	Fine
as1_pe_203.stp	AP203	3,848 tris · 192,484 B	6,088 tris · 304,484 B	17,848 tris · 892,484 B
as1-oc-214.stp	AP214	4,900 tris · 245,084 B	7,372 tris · 368,684 B	21,116 tris · 1,055,884 B

Every byte figure is the same identity: 84 bytes of header plus 50 bytes per triangle, so 84 + 50 × 6,088 = 304,484 and 84 + 50 × 7,372 = 368,684, and the same arithmetic closes on all six cells. The three presets are pairs of deviations — Draft 0.02 and 0.5, Normal 0.005 and 0.3, Fine 0.001 and 0.1 — and these are this site's own choices, not a CAD standard; the full cost table across seven files lives on the workflow page.

Why the counts differ — and why it is not the protocol

At the same preset the AP214 file comes out heavier than the AP203 file: +27.3% at Draft, +21.1% at Normal, +18.3% at Fine. If the protocol decided the mesh, two files describing the same assembly would land on the same count, and they do not. The headers say why. The FILE_NAME line sits just above FILE_SCHEMA and records the preprocessor that wrote the file: the AP203 file was written by Pro/ENGINEER in 2008, and the AP214 file came through a Datakit converter into Open CASCADE 6.1, also 2008. Two exporters, two ways of writing down the same exact surfaces — different edge curves, different surface splitting — and tessellation samples what is written, not what was intended. The mesh answers to the exporter's B-rep and to the quality setting; the protocol number is a passenger.

One exporter surplus, three presets. The AP214 file's surplus over the AP203 file shrinks from 27.3% at Draft to 18.3% at Fine and never reaches zero — which is exactly what an exporter difference looks like, and not what a protocol difference would: tightening the tolerance narrows how far two writings can drift, but cannot make them agree.

The words are older than the question

Both test files carry 2008 dates in their headers, and 2008 is also when the AP number meant the most as a decision. A snapshot of the conversion-service landscape from that year, preserved in the Wayback Machine, shows STEP conversion sold as enterprise software: CAD-to-CAD and CAD-to-visualisation processors listed by protocol — AP203, AP214, AP209 — with the customers named as automotive and aerospace makers and their supply chains. There was no self-service web conversion to speak of; putting STEP through its paces was a purchase, and the protocol name was a line item on the purchase order. The site in that snapshot has been gone for years — web records show its domain serving nothing real since 2015 — but the two words it sold by still sit in every STEP header written today. What changed is the question they answer: in 2008 the protocol was what you bought; today the flavour is a line you can read for free, and the decisions that shape your mesh — the quality setting, the tool that runs locally — are ones you make at conversion time, not procurement time.

What this means for your conversion

Treat the flavour as a fact, not a choice to agonise over. Either file converts: the engine reads both through the same reader, and no preset can tell the flavours apart.
Spend the decision where it lands. The quality setting is what changes the mesh — flat faces cost exactly 12 triangles at every setting, and curved faces are where Draft, Normal and Fine separate. The triangle-budget page works through that choice with measured counts.
Verify the output from the bytes. (size − 84) ÷ 50 must return a whole number for any binary STL; that is check 1 on the verification page, and it is indifferent to the flavour that produced the file.
If a tool refuses your file, the cause will not be the flavour. Refusals trace to the format family and what the reader links, which the verification page keeps as its single authoritative list.

Why the three benchmark sites cannot answer this

Of the three sites this project tracks — polyd.com, convert3d.org and imagetostl.com — none treats the header's protocol line as a topic. polyd's converter page prices its tiers as file-size caps and never reaches the header; convert3d's STEP page is a two-row compatibility table with no flavour dimension; imagetostl's STEP reference actually prints a real FILE_SCHEMA line inside a sample header — AUTOMOTIVE_DESIGN with the 214 tag — and then moves on without saying what the line means or what it changes. The cell this page occupies is the one they leave empty: read the line, know it does not steer the mesh, and know what does.

Where these numbers come from

3,848 / 6,088 / 17,848 and 4,900 / 7,372 / 21,116 triangles — the two 18-part test assemblies converted with the live engine at the shipped presets, re-run on every test pass. The byte sizes are the same identity: 84 + 50 × triangles, so 84 + 50 × 17,848 = 892,484 and 84 + 50 × 21,116 = 1,055,884.
136,663 and 433,606 bytes — the lengths of the two sample STEP files on disk, taken fresh by the suite each run.
+27.3% / +21.1% / +18.3% — computed from the live counts at each preset (4,900 ÷ 3,848, 7,372 ÷ 6,088, 21,116 ÷ 17,848, minus one), and the figure's three bars are drawn from the same numbers.
The two FILE_SCHEMA lines — quoted as they appear in the header of each sample file; the suite reads the files and requires the page to carry the same strings.
The 2008 procurement picture — from a Wayback Machine snapshot of a conversion-service page dated 2008, archived in this project's research log; recorded as a historical fact, with no comment on any company operating today.

npm test

The command above re-runs every number on this page. The workflow page keeps the short version of this answer beside the six conversion steps; the verification page owns the five checks and the colour-drop measurement; the triangle-budget page owns the quality decision; and the converter runs the whole thing in your tab with nothing uploaded.