Why Your DXF Imports at the Wrong Size

You draw a bracket 200 mm wide, export it as DXF, open it in your laser software, and it arrives 7.87 mm wide. Or 5080 mm wide. The shape is perfect — every curve, every hole in the right place — but the scale is nonsense.

The file isn’t corrupt. It’s unitless, and something downstream had to guess.

DXF coordinates are just numbers

This is the part that surprises people: a DXF file does not inherently know whether it is drawn in millimetres, inches, or furlongs. It stores bare coordinates. A square described as 200 units across is 200 somethings, and the format leaves the unit to a separate declaration in the file header.

That declaration is a header variable called $INSUNITS. It holds a small integer:

Value	Unit
0	Unitless
1	Inches
2	Feet
4	Millimetres
5	Centimetres
6	Metres

When $INSUNITS is present and correct, your CAD or CAM software places the geometry at 1:1 without being asked. When it’s missing, set to 0, or disagrees with the actual geometry, the receiving program falls back to whatever it assumes — and the part comes in wrong.

Where the number 25.4 comes from

There are 25.4 millimetres in an inch. That single conversion factor causes almost every DXF scaling complaint you’ll find.

If your geometry is in millimetres and the importer reads it as inches, every coordinate is treated as 25.4 times larger than intended — your 200 mm bracket becomes 200 inches, or 5080 mm. Run it the other way, with inch geometry read as millimetres, and the part shrinks to 1/25.4 of its size: a 8 in plate arrives 8 mm across.

So the direction of the error tells you which mistake happened:

• Part is 25.4× too big — millimetre geometry is being read as inches.
• Part is 25.4× too small — inch geometry is being read as millimetres.

Anything else — a part that’s 3.78× off, say — is usually a different problem, covered below.

The awkward history

$INSUNITS did not exist for most of DXF’s life. It was introduced with the AutoCAD 2000 file format. The older revisions — R12 in particular, which remains extremely common because almost everything can read it — have no official way to declare units at all. Files in those versions are unitless by definition.

That leaves exporters with an unpleasant choice: emit a modern DXF that can state its units but that some older machine controllers won’t parse, or emit the maximally compatible R12 and accept that the unit has to be communicated some other way. Plenty of tools take a third path and write $INSUNITS into an R12 file anyway, as a non-standard extension. Lenient importers read it; strict ones ignore it.

This is also why the historical default is inches. Before AutoCAD 2000, unitless files were simply assumed to be imperial by most software, and a lot of importers still carry that assumption forward.

Diagnosing it in thirty seconds

A DXF is plain text. Open it in any text editor and search for $INSUNITS. You’ll find something like:

9
$INSUNITS
70
4

The 70 is a group code and the value beneath it is what matters — 4 means millimetres. If the search finds nothing, your file has no unit declaration and every importer is guessing.

Next, sanity-check the geometry itself. Find a dimension you know, then look at the coordinate values in the ENTITIES section. If you drew a 200 mm plate and see numbers around 200, the geometry is in millimetres. If you see numbers around 7.87, it’s in inches. If you see roughly 755, the exporter wrote pixels — see the next section.

Between those two checks you can tell exactly what happened without opening a single CAD program.

The 96-versus-72 wrinkle

If your DXF came from vector artwork rather than CAD — an SVG, an Illustrator or Inkscape drawing — there’s a second failure mode that has nothing to do with inches.

Screen graphics are measured in pixels, and a pixel only becomes a physical size once you fix a resolution. The CSS specification pins that at 96 pixels per inch, so 96 px is exactly one inch, or 25.4 mm. Older tools used different numbers: Inkscape used 90 dpi before version 0.92, and Illustrator has historically treated SVG as 72 dpi.

Convert without accounting for this and your geometry arrives scaled by the ratio between two resolutions. A 96-versus-72 mismatch gives you a part 1.333× off. A 96-versus-90 mismatch gives 1.067× — small enough that it can slip past a casual glance and only show up when a joint doesn’t fit.

The tell is that the error is not a factor of 25.4. If your part is off by a third, or by a few percent, you’re looking at a resolution mismatch rather than a unit mismatch.

Fixing it

In your machine software. Every serious importer lets you state the units on the way in. In LightBurn the setting lives in the DXF import options; in Fusion 360 the import dialog asks; in AutoCAD the INSUNITS system variable controls it. If the geometry is correct and only the interpretation is wrong, this is a one-click fix and nothing needs re-exporting.

By rescaling. If you can’t set import units, scale the whole drawing by 25.4 or 1/25.4 after import. Measure a known feature first and confirm the factor before committing — guessing here is how you end up 645× off, having applied the correction twice.

At the source, which is the real fix. Set your drawing to real-world units before exporting. In Inkscape, that means File → Document Properties with the display units set to millimetres, and the document sized in millimetres rather than pixels. In Illustrator, set the artboard units. An SVG whose root element says width="200mm" carries a genuine physical size that a converter can honour exactly; one that says width="200" carries only pixels, and someone downstream has to assume a resolution.

Verify before you cut

Whatever route you take, measure something before the material goes in the machine. Pick a feature whose size you know — an overall width, a mounting hole spacing — and measure it in your CAM software. It takes a few seconds and it’s the only check that actually catches this class of error.

The failure mode here is unusually expensive relative to how easy it is to prevent: the file looks completely correct on screen, and the mistake only becomes visible once a laser has already moved through a sheet of material.

Converting SVG artwork to DXF

SVG to DXF handles the units side of this directly. It reads the physical size declared in your SVG — 200mm from Inkscape stays exactly 200 mm — and falls back to the CSS-standard 96 dpi for artwork that only carries pixels. You pick millimetres or inches, the geometry is written at true size, and the tool shows you the finished real-world dimensions before you download, so the verification step above happens automatically.

It runs entirely in your browser, so nothing is uploaded, and there’s no file size cap or conversion queue.

If you’re preparing artwork specifically for a laser or CNC router, SVG to DXF for laser cutting covers the export settings that avoid the other common failures — text that vanishes, open paths, and curves that arrive as jagged polylines.