SLDPRT File Documentation


Summary

A .sldprt file is a SOLIDWORKS Part File: a single 3D part modelled in SOLIDWORKS, the mechanical CAD program from Dassault Systèmes. It stores the solid geometry plus the full feature history (sketches, extrudes, cuts, fillets) inside a Microsoft OLE2 compound-file container. Editing needs SOLIDWORKS (paid, Windows), but the free eDrawings Viewer opens one to view and measure. For 3D printing, export to STL; to share with other CAD tools, export to STEP.

Technical details

FeatureValue
Full nameSOLIDWORKS Part File
File extension.sldprt
MIME typeapplication/octet-stream (also seen as application/sldworks)
DeveloperDassault Systèmes (SOLIDWORKS brand)
Introduced1995 (SOLIDWORKS 95)
Format typeProprietary binary 3D CAD part
Container / base formatMicrosoft OLE2 / Compound File Binary (CFB)
Open standardNo — closed and version-specific
BinaryYes
Byte orderLittle-endian (CFB header field, offset 28)
Magic number (hex)D0 CF 11 E0 A1 B1 1A E1 (offset 0)
Geometry kernelParasolid (boundary representation, B-rep)
Stored dataSolid/surface geometry, feature tree, custom properties, embedded preview
Holds per fileExactly one part
Backward compatibilityNewer SOLIDWORKS opens older parts; older cannot open newer
Free viewereDrawings Viewer (Windows, macOS, iOS, Android)
Related extensions.sldasm, .slddrw, .step, .iges, .x_t, .stl
Interchange exportsSTEP (CAD), STL/OBJ (mesh, 3D print), IGES, Parasolid (.x_t)
AutomationSOLIDWORKS API (COM)
Specification URLsolidworks.com
File signature (magic bytes)
D0 CF 11 E0 A1 B1 1A E1

Offset 0, 8 bytes. This is the Microsoft OLE2 / Compound File Binary (CFB) signature, not a SOLIDWORKS-specific marker: a .sldprt shares this exact header with legacy .doc/.xls, and with SOLIDWORKS .sldasm and .slddrw. The file is only confirmed as a part by its internal streams and the .sldprt extension. The signature is followed by a 512-byte CFB header whose fields (sector size, FAT location, root-directory offset) describe the compound structure. The stored geometry uses Dassault’s Parasolid-based kernel.

What is a SLDPRT file?

A .sldprt file is the native part document of SOLIDWORKS, the mechanical 3D CAD application Dassault Systèmes first shipped as SOLIDWORKS 95 in 1995. One file holds exactly one part: a single solid, sheet-metal, or surface body together with the complete recipe used to build it. That recipe is what separates a CAD part from a mere mesh. Instead of storing only the final triangles, a .sldprt records the ordered sequence of sketches and features (an extrude, then a cut, then a fillet) plus the dimensions and relations that drive them, so an engineer can change a dimension and have the whole part rebuild.

Parts are the atoms of the SOLIDWORKS document model. They are combined into assemblies (.sldasm) and documented in 2D drawings (.slddrw); those three extensions are the core file types and share the same on-disk container. This article looks at that container, how the feature history and geometry are stored inside it, why the format is version-locked, and what actually happens when you export to STEP or STL.

The OLE2 compound-file container

A .sldprt is not a flat binary blob. It is a Microsoft OLE2 Compound File Binary (CFB) document, the same container Microsoft used for legacy .doc and .xls files. CFB implements a small file system inside a single file, which is how one .sldprt can bundle the geometry, the feature tree, custom properties, and preview images as separate internal streams. Every CFB file opens with the same 8-byte signature.

Offset  Size  Field
  0     8     signature   D0 CF 11 E0 A1 B1 1A E1
  8    16     CLSID       (usually zeros)
 24     2     minor version
 26     2     major version (3 => 512-byte sectors, 4 => 4096)
 28     2     byte order  FE FF = little-endian
 30     2     sector shift (9 => 2^9 = 512-byte sectors)
 44     4     number of FAT sectors
 48     4     first directory sector
 ...          FAT / MiniFAT / DIFAT locations follow

After the 512-byte header the file is divided into fixed-size sectors (512 bytes in the common version 3). Sectors are chained through a File Allocation Table exactly like clusters on a disk, and a directory of entries names each “storage” (folder) and “stream” (file) and points at its starting sector. Small streams are packed into a MiniFAT to avoid wasting whole sectors. A generic CFB reader can therefore list the internal streams of a .sldprt without understanding SOLIDWORKS at all, which is how forensic and thumbnailing tools pull the embedded preview out of a part they cannot otherwise open. Because the header signature is shared, the byte pattern alone cannot tell a part from a DOC, a .sldasm assembly, or a .slddrw drawing; the distinguishing evidence is the set of named streams inside and the file extension.

B-rep geometry and the Parasolid kernel

The 3D shape itself is stored as a boundary representation (B-rep): the part is described as a closed set of trimmed surfaces (faces), the curves where they meet (edges), and the points where edges meet (vertices), with the topology recording which face borders which. This is fundamentally different from a triangle mesh. A B-rep cylinder is one exact analytic surface with a radius; a mesh cylinder is hundreds of flat facets approximating it. SOLIDWORKS computes and stores this geometry with the Parasolid modelling kernel, also owned within the CAD industry and licensed by many programs, which is why a Parasolid export (.x_t/.x_b) round-trips so cleanly to other Parasolid-based tools. Inside the compound file the kernel data lives in its own stream, distinct from the feature history that generated it.

The feature tree: parametric history

The stream most people think of as “the model” is actually the feature tree, the ordered list shown in the SOLIDWORKS FeatureManager. Each entry is a modelling operation with its parameters: a sketch on a named plane, an extrude of that sketch to a given depth, a fillet applied to selected edges with a radius, a linear pattern with a count and spacing. Crucially the tree stores relationships, not just results. A dimension can be tied to another dimension by an equation, and a sketch can be constrained “concentric” or “coincident” to existing geometry. When any driving value changes, SOLIDWORKS replays the tree from the top and rebuilds the B-rep. That replay is the whole point of parametric CAD, and it is the part of a .sldprt that no neutral export format preserves.

Alongside the tree, the file carries custom properties (part number, material, author, revision, and any configuration-specific overrides) in their own stream. A single part file can hold multiple configurations, which are named variations of the same part (different hole sizes, a “simplified” version for assemblies), each recorded as a set of suppressed features and overridden dimensions rather than as a duplicate body.

The embedded preview and display data

To let file browsers and viewers show a part without a full CAD rebuild, SOLIDWORKS embeds a preview: a bitmap thumbnail plus tessellated (triangulated) display geometry. This is why eDrawings and Windows Explorer can show a picture of a part almost instantly, and why the eDrawings Viewer can rotate and measure a part it is only displaying, not editing. The tessellation is a mesh derived from the exact B-rep purely for the screen; it is not the geometry a downstream CAD tool would use. The distinction matters when exporting: viewing uses the cached mesh, while an accurate STEP export re-reads the precise B-rep.

Why an older SOLIDWORKS cannot open a newer part

The .sldprt format is closed and tied to the release that wrote it. SOLIDWORKS is strictly forward-compatible: a 2024 build opens a part saved in 2015, but a 2015 build cannot open a part saved in 2024, and there is usually no “save as older version” that spans many releases. The practical reason is that new releases add new feature types and new stream layouts that older parsers do not recognise, and unlike the ISO BMFF boxes of an MP4 (where an unknown box is simply skipped), an unknown SOLIDWORKS feature cannot be safely ignored without corrupting the parametric rebuild. The standard workaround when someone sends a part your SOLIDWORKS is too old to open is to ask them to export a neutral STEP or STL file, which is version-independent.

STEP, STL and Parasolid: what each export keeps

Because the native format is locked, moving a part to another program means exporting through a neutral format, and each one keeps a different slice of the file. STEP (ISO 10303, .step/.stp) carries the exact B-rep solid geometry and is read by virtually every CAD system (Fusion 360, Inventor, FreeCAD, Onshape); it is the right choice for CAD-to-CAD exchange, but the feature tree does not travel, so the receiver gets a “dumb” solid rather than an editable history. STL and OBJ throw away the surfaces entirely and keep only a triangle mesh, which is exactly what a 3D printer’s slicer wants; mesh resolution is chosen at export time and cannot be increased afterward. Parasolid (.x_t/.x_b) is the closest to lossless for geometry because it is the kernel’s own format. IGES is an older surface/solid exchange format, generally superseded by STEP. In every case the export is a one-way flattening: the sketches, dimensions, and relations that made the part parametric stay behind in the .sldprt.

Frequently asked questions

Why does a SLDPRT start with the same bytes as a Word document?

Both use Microsoft’s OLE2 Compound File Binary container, whose fixed signature is D0 CF 11 E0 A1 B1 1A E1. The container is a generic “file system in a file”; SOLIDWORKS and old Office simply store different internal streams inside it. A tool must inspect those streams (or trust the extension) to tell a part from a document.

Why does exporting to STEP lose the feature tree?

STEP is a geometry-exchange standard: it describes the final B-rep solid, not the parametric operations that produced it. The sketches, extrude depths, fillet radii, and equations live only in the SOLIDWORKS-specific streams of the .sldprt, so a STEP file gives the receiver an exact but non-editable solid.

References