DWG File Documentation

Summary

A DWG file is an AutoCAD Drawing Database, the native binary CAD format of Autodesk AutoCAD. It is not an image but a database of 2D/3D geometry, layers, blocks and annotation, used for architectural, engineering and mechanical drawings. Its extension is .dwg and its MIME type is image/vnd.dwg. The exact format version is written in the first six bytes (for example AC1032 = the AutoCAD 2018 format). View it free with Autodesk DWG TrueView or the ODA Drawings Explorer.

Technical details

FeatureValue
Full nameAutoCAD Drawing Database
File extension.dwg
MIME typeimage/vnd.dwg
Format typeProprietary binary CAD database (2D/3D geometry)
DeveloperAutodesk
Introduced1982 (AutoCAD 1.0)
Open standardNo — proprietary; ODA maintains a reverse-engineered spec
Byte orderLittle-endian
Vector or rasterVector geometry database (with embedded raster thumbnail)
CompressionYes — proprietary, section-based
Version string (offset 0)AC1032 = 2018 format; AC1027 = 2013; AC1024 = 2010; AC1021 = 2007; AC1018 = 2004; AC1015 = 2000
Magic number (hex)41 43 31 30 33 32 (ASCII AC1032)
ContainsLines, arcs, polylines, 3D solids, layers, blocks, xrefs, dimensions, layouts
Layer supportYes
Embedded previewYes — BMP/PNG thumbnail referenced from the header
Executable contentPossible — AutoLISP/VBA may auto-load alongside a drawing
Forward compatibleNo — older AutoCAD cannot open a newer format version
Exchange siblingDXF (documented text/binary interchange format)
Related extensions.dxf, .dwt, .dws, .dwf, .bak
Specificationopendesign.com (Open Design Alliance .dwg spec)
File signature (magic bytes)
41 43 31 30 33 32

Offset 0, 6 bytes of ASCII. This reads A C 1 0 3 2, the version string for the AutoCAD 2018 DWG format (current through AutoCAD 2026). The first two characters are always AC; the four digits encode the release: AC1027 = 2013–2017, AC1024 = 2010–2012, AC1021 = 2007–2009, AC1018 = 2004, AC1015 = 2000. Reading these six bytes tells you at once whether your CAD program is new enough to open the file — the “created by a newer version” error is simply the reader rejecting a version code it does not know.

What is a DWG file?

DWG (short for “drawing”) is the native binary file format of Autodesk AutoCAD, in continuous use since AutoCAD 1.0 shipped in December 1982. A DWG is not an image. It is a database that stores the objects making up a technical drawing: geometry (lines, arcs, polylines, 3D solids), organisation (layers, blocks, external references), annotation (dimensions, text, tables) and the paper-space layouts prepared for plotting. A single file routinely holds an entire building floor plan or a complete machine part. Its MIME type is image/vnd.dwg.

The format is proprietary and has never been publicly documented by Autodesk. The reason non-Autodesk tools such as BricsCAD, DraftSight and ZWCAD can still read DWG is the Open Design Alliance (ODA), which publishes a reverse-engineered specification and SDK that most of the industry builds on. The internal layout changes every few AutoCAD releases, and the exact version is written in plain ASCII in the first six bytes of every file. That version string, the section layout it introduces, and the object database it points to are what the rest of this article describes.

The version header: AC10xx and the maintenance fields

Every DWG file opens with a six-byte version string in ASCII. The first two bytes are always AC; the following four digits identify the format release. AC1032 is the AutoCAD 2018 format, still current for AutoCAD 2018 through 2026; earlier codes map to earlier releases (AC1027 = 2013, AC1024 = 2010, AC1021 = 2007, AC1018 = 2004, AC1015 = 2000). Because the codes are not forward-compatible, this string is exactly what a reader checks first, and mismatching it is the source of the familiar “drawing was created by a newer version” message.

Offset  Size  Field
0x00    6     Version ID, ASCII "AC1032" (or AC1027, AC1024, ...)
0x06    5     Five null bytes (reserved)
0x0B    1     Maintenance release version byte
0x0C    1     Byte 0x00 or 0x01 (app marker)
0x0D    4     Seeker: absolute file offset of the preview/image data
0x11    1     DWG version (release-specific)
0x12    1     Application maintenance-release version
0x13    2     Code page (character set) for text in the drawing
0x15    4     Number of section-locator records that follow

After the version string come five reserved null bytes and a maintenance-version byte at offset 0x0B. The 4-byte value at offset 0x0D is a seeker: an absolute file offset pointing at the beginning of the embedded preview image, so a file browser can jump straight to the thumbnail without parsing the drawing. Offsets 0x13–0x14 hold the code page that decodes text objects, and the 4-byte count at 0x15 says how many section-locator records follow. All multi-byte integers are little-endian.

The section-locator records and file sections

A DWG is not one flat stream. It is divided into named sections (the header variables, the class definitions, the object map, the object data, the preview image and others), and the reader finds them through a table of section-locator records that immediately follows the file header. Each record is a fixed triple.

Section-locator record (repeated, count read from offset 0x15):
  Record number : 1 byte   (which section: header, classes, objects, ...)
  Seeker        : 4 bytes  (absolute file offset where the section starts)
  Size          : 4 bytes  (length of the section in bytes)

This is a self-locating design: a reader does not scan the file looking for sections, it reads the locator table and jumps directly to each one by offset. That is why the format tolerates the proprietary, section-based compression Autodesk applies to the object data, and why a corrupt locator table (rather than corrupt geometry) is a common cause of a drawing that will not open until AutoCAD’s AUDIT/RECOVER runs. The header section itself stores the hundreds of drawing variables (units, current layer, dimension styles) that AutoCAD exposes as system variables.

Objects, handles and the object map

The heart of a DWG is its object database. Every entity and every non-graphical object in the drawing (a line, a layer definition, a block record, a dictionary) is stored as an object with a unique handle, a persistent identifier that never changes for the life of that object. Objects reference each other by handle: an entity names the handle of the layer it sits on, a block insertion names the handle of the block definition it instantiates, and so on. The drawing is effectively a graph of handle references, not a flat list.

To reach a given object by handle without reading the whole file, the DWG carries an object map (also called the handle map): a table pairing each object handle with the absolute file offset of that object’s data. A reader resolves a reference by looking the handle up in the map and seeking to the offset. Individual objects are bit-packed rather than byte-aligned; the ODA specification documents the bitwise encodings (bit-shorts, bit-doubles, modular characters) that let common values such as small integers and colour indices occupy only a few bits each, which is a large part of why DWG files are far smaller than the equivalent text DXF.

Blocks, layers and external references

Three organising structures dominate a real drawing. Layers group objects for visibility, colour and plot style; each entity stores the handle of its layer, and the layer table object holds the name, colour, linetype and on/off/frozen flags. Blocks are reusable definitions (a door, a bolt, a title block) stored once in a block record; each placement is a lightweight INSERT entity that references the block’s handle plus an insertion point, scale and rotation, so a plan with 200 identical doors stores the door geometry once. External references (xrefs) are blocks whose content lives in another DWG file and is linked in at open time, which is how large projects split a building across many drawings that share a common base plan.

Because these relationships are handle-based and the geometry is stored once and instanced, editing a block definition updates every insertion, and a broken xref path leaves a resolvable placeholder rather than corrupting the host drawing. The same structure explains why a DWG can be simultaneously 2D and 3D: 3D solids are simply another entity type in the object database, stored in the same file as the 2D line work.

The embedded preview image

The seeker at offset 0x0D of the header points at a preview image section holding a small raster thumbnail (BMP or PNG) rendered from the drawing. This is what Windows Explorer and CAD file browsers display without launching AutoCAD or parsing the object database. The preview is a rendered snapshot, not live geometry, so it can be stale if a file was saved by a tool that did not regenerate it, and it is the one part of the file a non-CAD image viewer can meaningfully extract.

DWG versus DXF: compact database against documented exchange

DWG’s sibling is DXF, the Drawing Interchange Format. They carry the same kind of content (the same entities, layers and blocks), but DXF is Autodesk’s documented exchange format, written as tagged ASCII (or a documented binary variant) that any program can parse without reverse engineering. DWG is the compact, bit-packed proprietary native format. The practical consequence: when a tool cannot read DWG directly, converting to DXF with the free ODA File Converter is the standard workaround, and the conversion is lossless for geometry because both describe the same object model. DWG is smaller and faster; DXF is portable and readable.

References