SLDDRW File Documentation

Summary

A SOLIDWORKS Drawing File is the native 2D engineering drawing produced by SOLIDWORKS, holding dimensioned views, sections, notes and a title block that document a 3D part or assembly. The .slddrw file is a binary stored in Microsoft’s OLE2 compound container, so its MIME type is the generic application/octet-stream. Editing needs SOLIDWORKS (Windows, paid); the free eDrawings Viewer opens it to view, measure and print.

Technical details

FeatureValue
Full nameSOLIDWORKS Drawing File
File extension.slddrw
MIME typeapplication/octet-stream
Format type2D CAD drawing, binary
Container / base formatMicrosoft OLE2 / Compound File Binary (CFB)
DeveloperDassault Systèmes (SOLIDWORKS)
Introduced1995 (SOLIDWORKS 95)
Open standardNo — proprietary, version-specific
Byte orderLittle-endian (CFB)
Magic number (hex)D0 CF 11 E0 A1 B1 1A E1
Model dependencyViews reference external .sldprt / .sldasm files
ContentsSheets, views, dimensions, tolerances, annotations, BOM, embedded preview
Embedded previewYes — thumbnail stream for display without a rebuild
Native editorSOLIDWORKS (Windows only, paid)
Free viewereDrawings Viewer (Windows, macOS, iOS, Android)
Valid 2D exports.pdf, .dwg, .dxf, .jpg
Related extensions.sldprt, .sldasm, .slddrt, .dwg, .dxf, .edrw
Specificationsolidworks.com (closed)
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, the same header used by legacy .doc and .xls files and by the other SOLIDWORKS formats (.sldprt parts and .sldasm assemblies). Because the magic bytes only identify the CFB wrapper, a .slddrw is recognised by the .slddrw extension and by the SOLIDWORKS-specific streams stored inside the compound file, not by the header alone.

What is a SLDDRW file?

A .slddrw file is the native 2D SOLIDWORKS Drawing File: the engineering drawing that documents a 3D model with dimensioned orthographic views, section and detail views, tolerances, annotations, a bill of materials and a title block. SOLIDWORKS is the mechanical CAD application first released in 1995 and now owned by Dassault Systèmes. The drawing is the third core file type in the SOLIDWORKS family, alongside the part (.sldprt) and the assembly (.sldasm). Where those two hold 3D geometry, the drawing holds the 2D sheets a shop actually manufactures from.

The single most important fact about the format is that a drawing is not self-contained. Each view on a sheet is a live projection of a referenced .sldprt or .sldasm, and dimensions update when the model changes. Open a .slddrw without the model files it points to and the views can come up blank, because SOLIDWORKS needs the referenced geometry to rebuild them. Everything below describes how the file is physically stored and why that reference behaviour exists.

The OLE2 compound container

A .slddrw is a binary file wrapped in Microsoft’s OLE2 Compound File Binary format (CFB), also called a structured storage file. This is the same container that holds legacy Office documents such as .doc and .xls, and the same wrapper used by SOLIDWORKS parts and assemblies. That is why all three SOLIDWORKS formats, and old Word files, share the identical first eight bytes.

offset 0x00:  D0 CF 11 E0 A1 B1 1A E1   CFB signature (8 bytes)
offset 0x08:  16-byte CLSID (usually zero)
offset 0x18:  minor + major version, byte-order mark FE FF (little-endian)
offset 0x1E:  sector shift (0x0009 => 512-byte sectors, or 0x000C => 4096)
              ... FAT, directory and mini-stream sector chains ...

A CFB file is effectively a small file system inside one file. It is divided into fixed-size sectors (512 bytes in the classic version 3 layout) chained together by a file allocation table, exactly like an old FAT disk. Within it live named storages (the directories) and streams (the files). SOLIDWORKS writes its drawing data into these internal streams: the sheet definitions, the view records, the reference links to the model, the annotations and an embedded preview image all sit as separate streams under the compound file’s root. A generic CFB reader can walk that directory tree and list the streams, but it cannot interpret their contents, because the byte layout inside each SOLIDWORKS stream is proprietary and undocumented.

Why the magic bytes do not identify the drawing

Because the D0 CF 11 E0 A1 B1 1A E1 signature only marks the CFB wrapper, it cannot on its own tell a .slddrw apart from a .sldprt, a .sldasm or a 1990s Word document. The real identity lives one level deeper, in the CLSID recorded in the compound file’s root directory entry and in the names of the internal streams. A drawing carries the SOLIDWORKS drawing class identifier and drawing-specific streams; a part carries the part class. In practice, tools rely on the .slddrw extension plus these internal markers to classify the file. This layering is worth understanding: the outer container is a documented Microsoft format, while the payload it carries is a closed vendor format.

Sheets, views and the reference graph

Inside the container the drawing is organised as one or more sheets. A sheet has a paper size, a scale and a title block (often drawn from a separate sheet-format template, the .slddrt file). Onto each sheet the author places views: standard orthographic projections (front, top, right), isometric views, section views cut through the model, detail views that magnify a region, and auxiliary views. Every one of these is a derived projection, not baked-in line art. The view record stores which model it projects, the projection direction, the scale, and the display state; the geometry itself is regenerated from the referenced .sldprt or .sldasm.

This is the reference graph that trips people up. A single assembly drawing can reference a top-level .sldasm, which in turn references dozens of .sldprt files. If the sender ships only the .slddrw, SOLIDWORKS has nothing to rebuild the views from. The fix is the SOLIDWORKS “Pack and Go” feature, which gathers the drawing and every referenced part and assembly into one bundle. An embedded preview stream stored inside the file lets a viewer show a thumbnail of the last-saved state without any rebuild at all, which is how thumbnails still appear even when the references are missing.

Dimensions, tolerances and the bill of materials

Beyond the views, a drawing holds the manufacturing intent. Dimensions can be imported from the model (so they stay associative) or added in the drawing. Geometric dimensioning and tolerancing (GD&T) frames, surface-finish symbols, weld symbols, datum references and general notes are stored as annotation entities attached to sheets or views. Assembly drawings add a bill of materials table listing every component, its quantity and its part number, and balloon callouts that tie each BOM row to a component in the views. All of this is exact manufacturing data, which is one reason a shared .slddrw should be treated as intellectual property: it often contains the precise dimensions and tolerances needed to reproduce a part.

Version-specific storage and forward incompatibility

The SOLIDWORKS file format is closed and tied to release. A newer SOLIDWORKS opens drawings saved by any older release, but an older SOLIDWORKS generally cannot open a drawing saved by a newer one, because the internal stream layout changed between versions and the old reader does not understand the new records. There is no “save as older version” that spans many releases; at most SOLIDWORKS can save back one service pack. When a colleague cannot open your drawing, the cause is almost always this version gap rather than a corrupt file. The practical escape hatch is to export a neutral format that carries no version dependency.

2D exports versus impossible 3D exports

Because a .slddrw is already a 2D drawing, it maps cleanly to other 2D formats. Exporting to PDF produces a fixed, printable copy anyone can open, and is the usual way to send prints to a shop floor or into a quote. Exporting to DWG or DXF moves the drawing into AutoCAD or a neutral CAD exchange, which is well suited to laser cutting and CNC because those consumers want 2D profiles. A raster export to JPG or PNG produces a flat picture of a sheet.

What you cannot do is export a .slddrw to a 3D format such as STEP, IGES or a .sldprt. A drawing has no 3D solid to write out; it only projects one. STEP, STP and IGES are 3D solid-model exchange formats, so to obtain them you must export the underlying .sldprt or .sldasm that the drawing references, not the drawing itself. Databases that list slddrw → step conversions are conflating the drawing with the model it documents; the conversion is not real.

Viewing a drawing without SOLIDWORKS

There is no free full editor for the format, but Dassault publishes a free official viewer, eDrawings Viewer, for Windows and macOS with companion iOS and Android apps. It renders drawing sheets faithfully, including dimensions and the title block, and lets you zoom, measure and print. When the sender uses the eDrawings publish option they can embed the referenced geometry so the views display correctly even on a machine that has neither SOLIDWORKS nor the source model files. SOLIDWORKS itself is Windows-only; there is no native macOS build, so on a Mac the viewer is the way to open a .slddrw.

Frequently asked questions

Why does my SLDDRW open with blank or missing views?

A drawing stores references to the 3D part or assembly it documents rather than a copy of that geometry, so the views are rebuilt from the model at open time. If the referenced .sldprt or .sldasm files were not included, SOLIDWORKS cannot rebuild the views and they appear empty. Ask the sender to use Pack and Go to include every reference, or to send a PDF.

Why can an older SOLIDWORKS not open my drawing?

The format is version-specific. A newer release can read older drawings, but the internal stream layout evolves each version, so an older release cannot parse records written by a newer one. Save from the machine that has the newer version, or export a neutral PDF/DWG/DXF that has no version dependency.

References