DXF to SVG and PDF: what survives and what does not

Why DXF and not DWG

DWG is AutoCAD's native format and it is proprietary. Its specification is not openly published, and the only reliable converters are commercial products — Autodesk's own tools, or the ODA File Converter. There is no honest open-source path, so DWG is not supported here at all.

DXF is the interchange format Autodesk publishes precisely so other software can read it. Every CAD package can export it. If you need to get a drawing out of AutoCAD and into anything else, DXF is the door, and exporting to DXF first is the required step.

How the conversion works

The DXF is parsed by ezdxf, which reads the drawing's entities — lines, arcs, circles, polylines, text, hatches, dimensions — as structured objects rather than as a picture. Its drawing module then renders those entities through a matplotlib backend running headlessly, and matplotlib writes the output.

That last step is what determines the output type. SVG, PDF, and EPS come out as vector files, with the geometry preserved as paths that scale cleanly to any size. PNG comes out as a raster render at a fixed resolution.

What gets drawn: modelspace only

A DXF file has two kinds of space. Modelspace is where the drawing itself lives, at real-world scale. Paper space holds the layouts — the title blocks, the sheet borders, the viewports that frame parts of the model at particular scales for printing.

The conversion renders modelspace. Paper-space layouts, title blocks, sheet borders, and viewport arrangements are not part of the export.

This matters more than it sounds, because a drawing set that has been carefully laid out for printing is largely paper-space work. If what you need is the sheet as it would print, the right move is to produce the PDF from the CAD application, which knows about layouts. If what you need is the geometry, converting the DXF is exactly right.

Other things worth expecting

• Text is rendered as drawn. It appears correctly in the output, but in a vector target it is generally paths rather than live, selectable text — so do not expect to edit the labels afterwards.
• Layers are flattened into the render. The visual result is correct; the layer structure is not carried into SVG or PDF as separate groups you can toggle.
• Dimensions render as the lines and text that make them up, not as live dimension objects. Changing the geometry afterwards will not update the number.
• Very large or dense drawings take longer and produce large SVG files. If the drawing has tens of thousands of entities, PDF usually handles it more gracefully than SVG in a browser.

There is no way back

Nothing here writes DXF. That is deliberate, and it is worth explaining because it is a reasonable thing to want.

Converting a PNG to DXF would mean tracing a raster image and inferring where the lines were — and then inferring which of those traced lines were meant to be circles, which were dimension leaders, and what the layer structure was. Converting an SVG or PDF to DXF is less hopeless, because the paths are real, but a path is not a CAD entity: it has no layer, no line type, no block reference, and no relationship to the rest of the drawing.

Producing something that opens in AutoCAD is easy. Producing something a drafter can actually work with is a different project, and a converter that claimed to do it would mostly be producing files that look right and are useless. CAD is a one-way street here.

Practical advice

For sending a drawing to a client or a contractor to look at: PDF. It prints correctly, it opens everywhere, and it is what people expect to receive.

For putting a drawing on a website or into a design tool: SVG. It stays crisp at every zoom level and it can be styled with CSS.

For a thumbnail or an image in a document: PNG.

And keep the DXF. It is the only version of the file that still contains a drawing rather than a picture of one.