SAT and STEP can both carry precise 3D geometry, so choosing between them is not a simple “accurate versus inaccurate” decision. The more useful question is which exchange ecosystem must receive the model.
SAT is the text representation of ACIS model data. STEP is a broader neutral product-data exchange standard used across many CAD systems. If both sides are working in an ACIS-friendly environment, SAT can be a direct solid-model handoff. If the recipient, supplier or downstream system is unknown or uses a different modeling kernel, STEP is usually the more portable default.
CADProps supports readable text SAT inputs for browser inspection and can create STEP output from supported SAT geometry. Binary SAB is not enabled in the current workflow.
SAT and STEP at a glance
| Question | SAT | STEP |
|---|---|---|
| Primary role | ACIS-oriented solid/surface exchange | Broad neutral CAD/product-model exchange |
| Geometry | Precise ACIS solids and surfaces | Precise geometry with topology; capabilities depend on application protocol and exporter/importer |
| Ecosystem | Closely tied to ACIS-capable software | Broad multi-vendor CAD interoperability |
| Human-readable form | SAT is ASCII text | Traditional STEP Part 21 files are commonly text-based |
| Binary counterpart | SAB exists, but is a different encoding | Other STEP encodings exist; typical .step/.stp handoffs use Part 21 text |
| Best default for unknown CAD recipients | More conditional | Usually safer |
| Native feature history | Not a portable promise | Not a portable promise |
Spatial, the company behind ACIS, describes SAT as the ASCII representation of ACIS model data and explicitly contrasts it with binary SAB. It also notes that SAT is closely tied to the ACIS ecosystem, whereas STEP is a broader neutral exchange standard. See Spatial's SAT overview.
NIST's STEP resources describe STEP as a standards-based way to exchange product-model information, including geometry and other engineering data depending on the implementation. See the NIST STEP File Analyzer and Viewer for the STEP side of that workflow.
Choose SAT when the receiving workflow is ACIS-friendly
SAT makes sense when the sender and receiver already know that the target system handles ACIS geometry well. In that situation, keeping the model close to an ACIS representation can be a practical interoperability choice.
Typical examples include an internal toolchain built around ACIS-capable applications or a known downstream application whose SAT importer has been validated with the source exporter.
Even then, “supports SAT” is not a universal compatibility guarantee. ACIS versions, application-specific attributes, tolerance handling and exporter/importer behavior can differ. When a SAT file fails, record which application and version produced it before assuming the geometry itself is corrupt.
Choose STEP for a mixed or unknown CAD chain
STEP is usually the safer starting point when a model will pass between different CAD vendors, suppliers or manufacturing systems and you cannot assume a common geometry kernel.
That does not mean every STEP transfer is lossless. A STEP export can still lose native feature history, application-specific constraints or unsupported data. The receiving system must still validate the geometry and units.
The advantage is standardization and breadth of support. For a supplier handoff across SolidWorks, NX, CATIA, Inventor and other systems, a well-validated STEP file is often easier to standardize than a kernel-specific exchange format.
If native editing matters, keep the original CAD master alongside either neutral derivative.
SAT is not the same as SAB
SAT and SAB represent ACIS data using different encodings. SAT is text; SAB is binary. Renaming .sab to .sat does not convert the file.
CADProps currently accepts supported SAT text inputs but does not enable SAB. If you receive SAB and need to use the CADProps workflow, ask the source application to export SAT or STEP instead of changing the extension.
This distinction is useful in troubleshooting because an extension mismatch can look like a reader failure even though the real problem is that the wrong encoding was supplied.
What CADProps can do with SAT today
For supported SAT files with readable geometry, the ACIS SAT viewer can be used to inspect the converted model and geometry properties. The goal is verification, not reconstruction of the source application's modeling history.
A sensible sequence is:
- Keep the original SAT unchanged.
- Open it and confirm the expected body or bodies are present.
- Check overall dimensions and one known feature against the drawing or sender's value.
- Review volume or surface properties only after the scale and model scope look correct.
- Create a STEP derivative if the receiving workflow needs neutral CAD exchange.
- Reopen that STEP file in the actual downstream system and repeat the critical checks.
A successful translation message is not enough to approve the derivative.
What to compare after SAT-to-STEP conversion
The most useful validation checks are geometric and contextual:
- source and destination units;
- overall X, Y and Z dimensions;
- expected solid/body count;
- orientation and placement;
- important holes, pockets and mating faces;
- volume for closed solids when it is meaningful;
- revision identification and controlling drawing/specification.
Do not expect STEP to reconstruct ACIS-native feature history or the original CAD application's parametric tree. Read Why a STEP Export Has No Feature Tree if a recipient expects the neutral file to behave like the source model.
Which format is better for suppliers?
If a supplier specifically asks for SAT and you know their CAD/CAM stack reads it reliably, SAT can be a valid deliverable. There is no benefit in translating a known-good ACIS handoff merely to follow a generic rule.
If the supplier base is mixed, or the same model must circulate through several unrelated systems, STEP is usually easier to standardize and validate across the chain.
In either case, the file extension alone is not enough context. Include the part/revision identifier, units, drawing or specification reference and the purpose of the model. A geometry file for quoting may not carry every requirement needed for production.
SAT versus STEP for long-term reuse
For long-lived engineering data, think beyond whether the file opens today. Ask which format your organization can validate repeatedly in future software versions and which one aligns with customer or supplier standards.
SAT can remain appropriate inside a stable ACIS-oriented workflow. STEP often has an advantage when the objective is vendor-neutral exchange and archival interoperability. The right answer depends on the receiving systems and the data that must survive, not on file size or extension popularity alone.
Quick decision rule
Use SAT when:
- the source and receiving workflows are known to support ACIS/SAT well;
- preserving a direct precise solid representation inside that ecosystem is useful;
- the exact SAT version path has been tested.
Use STEP when:
- recipients use mixed CAD systems;
- a supplier-neutral exchange format is required;
- the file will move through several downstream applications;
- your organization already validates STEP as its standard handoff.
Whichever format you choose, validate the actual output rather than assuming that “precise CAD format” means “identical result.” The CAD conversion checklist provides a repeatable review sequence.
Original article: CADProps · https://www.cadprops.com/guides/sat-vs-step/