What file does my cutter actually want?
SVG, DXF, PLT or G-code, and the answer is not a preference. Each machine takes some of them and not others, and two of them carry real units while the other two need telling.
By machine
| Machine | Takes | Units carried? |
|---|---|---|
| Cricut, Silhouette | SVG | yes, if written with real dimensions |
| Glowforge, xTool, most diode lasers | SVG | yes |
| LightBurn | SVG, DXF, AI | yes |
| Epilog, Trotec | Print driver, DXF | yes |
| Roland, Graphtec, Summa, USCutter | HPGL (.plt) | yes, 40 units per mm |
| CNC routers, plasma | DXF, G-code | DXF yes, G-code is absolute |
| Embroidery (Brother, Tajima, Janome) | PES, DST, JEF | stitches, not shapes |
Why HPGL is exactly 40 units per millimetre
HPGL was designed for pen plotters and its coordinate unit is 1/40th of a millimetre, or 0.025mm. That is not a convention a converter gets to choose: write the file at any other scale and the cutter cuts at the wrong size, silently, because the format has no field to disagree in.
Embroidery is a different job
A stitch file is not a shape. It is a list of needle positions with colour changes between them, and producing one means deciding stitch type, density, underlay and pull compensation. Converting artwork to stitches is called digitising, and it is a skilled job that tracing does not do.
What tracing does give you is the step before: a clean, closed, colour-separated vector for a digitiser to work from, which is what they will ask for anyway.
Why DXF and not SVG, when you have the choice
SVG has no native concept of physical units in the way CAD does. It has a viewBox and a width, and whether a program reads those as millimetres depends on the program. DXF has $INSUNITS, one variable, unambiguous, and every CAD package reads it. For anything where the size has to be exact, DXF is the safer container.
The exception is Cricut and Silhouette, which do not take DXF at all in their consumer software. There, SVG written with explicit physical dimensions is the answer.
DXF versions, briefly
R12 is the oldest version still in wide use and the most compatible: almost anything opens it, and it has no splines, so everything is lines, arcs and polylines. R2000 and later add true spline entities, which are more compact and more accurate for curves but are not understood by some older controllers.
If a file will not open, exporting as R12 is the first thing to try. If curves come in faceted when you wanted smooth, it is the opposite problem and you want a later version.
G-code is not portable
A G-code file is instructions for one controller. Feed rates, spindle or laser power words, and the safe Z height are all machine specific, and a file written for a diode laser will do something unhelpful on a router. Treat G-code as an output for a machine you have configured, not as an interchange format. DXF and SVG are the interchange formats.