DXF File Documentation

---

Technical details

Feature	Value
Full name	Drawing Exchange Format (AutoCAD DXF)
File extension	.dxf
MIME type	image/vnd.dxf
Format type	CAD vector drawing exchange format
Encoding	ASCII tagged data (group code/value pairs); binary variant exists
Developer	Autodesk
Introduced	1982, with AutoCAD 1.0
Open standard	Partial — documented by Autodesk, not an ISO/ECMA standard
Version marker	$ACADVER header variable (e.g. AC1027 = AutoCAD 2013 format)
Sections	HEADER, CLASSES, TABLES, BLOCKS, ENTITIES, OBJECTS, THUMBNAILIMAGE
Byte order (binary variant)	Little-endian
ASCII start marker	0 then SECTION (no fixed binary magic)
Binary sentinel	AutoCAD Binary DXF\r\n\x1A\x00 at offset 0
Geometry	2D and 3D: lines, arcs, polylines, circles, text, dimensions, meshes, 3DSOLID
Native sibling	DWG (AutoCAD's compact binary format)
Related extensions	.dwg, .dxb, .dwf, .step, .iges, .x_t, .svg, .stl
Specification	help.autodesk.com — DXF Reference

What is a DXF file?

DXF stands for Drawing Exchange Format. Autodesk published it with the first release of AutoCAD, version 1.0, in December 1982, for a single purpose: to let a drawing leave AutoCAD and be read by some other program. AutoCAD's own native format, DWG, was compact and proprietary; DXF was the documented text form that any developer could parse. That decision is why, four decades later, DXF is still the lowest-common-denominator handoff for 2D and 3D CAD geometry, understood by mechanical CAD, illustration tools, and the CAM software that drives laser cutters and CNC routers.

A DXF stores the same kinds of content as a DWG — lines, arcs, polylines, circles, text, dimensions, layers, blocks, and, in 3D files, meshes and solids — but in a plain, line-by-line encoding anyone can read. Open one in a text editor and you see it directly. The rest of this article is about how that encoding actually works: the group-code mechanism, the section layout, how a single line is represented, and how the format signals its version.

Group codes: the two-line record

Everything in an ASCII DXF is expressed as a group code / value pair, written on two consecutive lines. The first line is an integer, the group code, that says what the value means. The second line is the value itself. A parser reads the file two lines at a time and never has to guess: the code tells it both the data type and the semantic role.

  0        <- group code (integer)
SECTION    <- value for that code
  2
HEADER
  9
$ACADVER
  1
AC1027

The code number also encodes the value's type, by range. Codes 0–9 carry strings, 10–59 are double-precision floating-point (coordinates and distances), 60–79 are 16-bit integers, 90–99 are 32-bit integers, 210–239 hold the components of an extrusion direction, and 999 is a comment. A few codes are load-bearing across the whole format: 0 introduces an entity or a structural keyword such as SECTION, ENDSEC or EOF; 2 is a name; 8 is the layer an entity sits on; and the coordinate triple 10/20/30 gives a point's X, Y and Z as three separate records.

Because each record is self-labelling, a reader can skip any code it does not recognise and keep going. That is what makes DXF forgiving across versions and vendors: an entity type or an extended-data group added in a later AutoCAD release does not break an older parser, it just gets ignored.

HEADER, TABLES, BLOCKS, ENTITIES: the section layout

A DXF file is a sequence of named sections, each opened by a 0 / SECTION record and a 2 / <name> record, and closed by 0 / ENDSEC. The file ends with 0 / EOF. Six sections appear in a fixed order, and each holds a distinct part of the drawing.

HEADER          drawing-wide variables: $ACADVER, units, limits, extents
CLASSES         application-defined class definitions (used by later sections)
TABLES          named symbol tables: LAYER, LTYPE, STYLE, VPORT, DIMSTYLE...
BLOCKS          reusable block (component) geometry definitions
ENTITIES        the actual drawing: LINE, LWPOLYLINE, ARC, CIRCLE, TEXT...
OBJECTS         non-graphical objects: dictionaries, layouts, xrecords
THUMBNAILIMAGE  optional embedded preview bitmap

The HEADER section is a flat list of system variables, each written as a 9 / $VARNAME record followed by the variable's value. It records the drawing units, the extents (the bounding box of all geometry), and, most importantly for compatibility, $ACADVER. The TABLES section defines the named resources that entities refer to by name: every layer used in the drawing is declared here in the LAYER table with its colour and linetype, every text style in STYLE, every linetype pattern in LTYPE. An entity later says only 8 / WALLS; the properties of the WALLS layer live once in the TABLES section.

The BLOCKS section defines reusable components once; the ENTITIES section then places them and holds all the loose geometry of model space and the layouts. OBJECTS carries everything that is not drawable geometry — dictionaries, layout definitions, group and xrecord objects — and is the part that grew most as AutoCAD gained features.

How a single entity is encoded: the LINE

Inside ENTITIES, each drawing object is a 0 record naming its type, followed by the group codes that describe it. A straight line segment, the simplest entity, shows the pattern clearly:

  0
LINE            entity type
  8
0               layer name (layer "0")
 10
0.0             start point X   (code 10)
 20
0.0             start point Y   (code 20)
 30
0.0             start point Z   (code 30)
 11
100.0           end point X     (code 11)
 21
50.0            end point Y     (code 21)
 31
0.0             end point Z     (code 31)

The 10/20/30 triple is the start point and 11/21/31 is the end point; a Z of 0 makes it a 2D line. An LWPOLYLINE (lightweight polyline) instead lists a vertex count under code 90, then repeats 10/20 pairs for each vertex, which is why polylines are far more compact than a chain of separate LINE entities. A CIRCLE uses 10/20/30 for its centre and code 40 for the radius. The same handful of codes, reused with type-specific meaning, expresses the whole entity vocabulary.

The $ACADVER version marker and the AC codes

DXF versions track AutoCAD releases, and the file announces its version in the HEADER through the $ACADVER variable. Its value is an AC code, an internal release string rather than a marketing year:

$ACADVER	AutoCAD release / DXF version
AC1015	AutoCAD 2000
AC1018	AutoCAD 2004
AC1021	AutoCAD 2007
AC1024	AutoCAD 2010
AC1027	AutoCAD 2013
AC1032	AutoCAD 2018

This matters in practice. When old software reports that a DXF is "too new", it has read an $ACADVER it does not understand or has hit entities that only exist in a later schema. The fix is to re-export the drawing to an earlier version: any CAD editor's Save As lets you pick the DXF version, and choosing AC1018 (2004) or AC1015 (2000) produces a file that almost any tool from the last twenty years will read.

Binary DXF: the same data, without the text

There is a second, rarely used encoding. Binary DXF holds exactly the same group-code/value structure but writes codes and values as raw bytes instead of text lines, which makes the file smaller and faster to parse at the cost of being unreadable in an editor. You can identify it by its sentinel: a binary DXF begins at offset 0 with the literal 22-byte string AutoCAD Binary DXF followed by \r\n\x1A\x00. In binary form, integer group codes are stored as one or two bytes, coordinate values as little-endian IEEE doubles, and strings as null-terminated byte runs. The vast majority of DXF files in the wild are the ASCII form; binary DXF appears mostly as an export option chosen for size or speed.

DXF and DWG: same drawing, different packaging

DXF and DWG describe the same kinds of geometry, and Autodesk maintains both in lockstep — each AutoCAD release bumps both formats to the same schema, which is why they share the AC version codes. The difference is packaging. DWG is a compact, proprietary, binary container tuned for AutoCAD's own read/write speed; DXF is the documented, usually textual interchange form. Converting between them is lossless for geometry, and the free ODA File Converter batch-translates DXF and DWG across every version. For heavier 3D solid exchange, DXF is a poor carrier and engineers reach for the neutral STEP standard or Siemens' Parasolid (.x_t/.x_b) instead, because those formats store exact boundary-representation solids that DXF's entity model does not represent cleanly.

DXF as the fabrication handoff

The single most common modern use of DXF has nothing to do with AutoCAD drawings on paper. A 2D DXF profile is the standard input to computer-controlled cutting: laser cutters, CNC routers, plasma and waterjet machines, and vinyl cutters all accept a DXF of the cut outline. The reason is the format's simplicity — a closed loop of LINE, ARC and LWPOLYLINE entities is trivial for CAM software to trace into a toolpath. The DXF itself carries no cutting information; the CAM step (LightBurn, Fusion CAM, FreeCAD Path) adds tool, feed rate, speed and cut order and emits the G-code the machine runs. There is deliberately no one-click DXF-to-G-code, because the machining parameters are not part of the drawing.

References

• Autodesk — AutoCAD DXF Reference
• Library of Congress — DXF (Drawing Interchange Format) format description
• Open Design Alliance — ODA File Converter (free DXF<>DWG)

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.