DXF to CSV converter

Why convert DXF to CSV?

DXF packs survey lines, polylines, arcs and text into CAD layers that a spreadsheet cannot read. Converting DXF to CSV lays the drawing out as plain rows, with nothing redrawn and no shape lost: points become coordinate columns, and longer geometry travels as WKT text. Engineers pull points out of a site plan to check them, then feed the rows to pandas or a script. A simple table also lets non-CAD colleagues open the same data in Excel or Google Sheets.

Coordinate system handling

No field in a DXF records the grid, so a drawing whose values look projected prompts for one before the conversion runs, and the system you give it anchors the map preview, which is the quickest check that the right zone was named. A drawing already in longitude and latitude needs nothing declared and passes straight into the table.

Every tool that opens the table later asks for the system all over again: QGIS wants it typed into the delimited text import dialog, and geopandas wants it passed as a crs argument, because the columns themselves carry no declaration. Writing the EPSG code into the filename, something like points_epsg32643.csv, spares whoever imports the rows from guessing.

What to check when converting DXF to CSV

Most DXF files sit in a local or site coordinate system. The CSV holds those same engineering X and Y numbers unless you set a coordinate system before converting. CSV carries no tag for it, so note the system and the units for whoever opens the file, since a column of eastings in survey feet means something different the moment a reader assumes meters.

Troubleshooting DXF to CSV

• The Z column is there but holds nothing except zeros. A 2D drawing stores every entity at elevation zero, and the table reports that honestly. Real heights appear only when the source carried them, so a column of zeros means the drawing was flat, not that elevations were dropped on the way through; delete the column if it misleads anyone downstream.
• Station labels sit on their own rows instead of beside their points. A text entity is independent geometry in a drawing, so each label becomes a row at its own insertion point with the wording in its text field, while the survey point becomes a separate row. The drawing never linked the two; join them afterward by nearest coordinates in QGIS or a short script.
• The table has far more rows than the drawing seemed to contain. Layers switched off or frozen in CAD still hold entities, and every one of them converts, because visibility settings describe the screen rather than the file. Filter the Layer column in the spreadsheet down to what you need, or delete the unwanted layers in CAD and convert again.
• You expected a row per survey point and got one row per line. A polyline is a single entity, so its whole run of vertices lands in one WKT cell rather than one row each. Explode the polylines in CAD before converting when the deliverable needs individual vertices, or pull the LINESTRING text apart in a script afterward.
• Two drawings of the same site land kilometers apart as tables. One file was drafted on the survey grid and the other against a local origin near zero, and CAD happily displays both without complaint. The tables simply report those stored numbers, so transform the local drawing onto the grid in CAD, or record each file's basis and shift the rows in a script.

About the formats

DXF holds CAD linework: polylines, arcs, text and layers drawn in AutoCAD or Civil 3D. CSV is a flat table of rows and columns, and the conversion fills it with everything the drawing exposes: X and Y from point entities, WKT geometry for lines and polygons, and Z where elevation is present, plus layer, color, line weight and line style. The content of text entities comes along as a field too, so labels survive the trip into the table.

Related converters