SVG to Laser-Ready DXF: The Complete Guide

Do You Actually Need a DXF? When SVG Is Fine and When DXF Is Required

Before converting anything, the most useful question to answer is whether DXF is the right format for your specific workflow. The answer is not always yes — and converting unnecessarily adds a step without adding value.

LightBurn accepts SVG natively and handles it well. If you are working entirely within LightBurn on your own machine with your own SVG files, staying in SVG is simpler and equally reliable. LightBurn reads SVG path colours, assigns layers automatically, preserves group structure, and imports at correct physical dimensions when the file's width, height, and viewBox attributes are properly declared. For a solo LightBurn workflow, SVG is the right choice.

DXF is required in four specific situations. First, when delivering a file to an external laser cutting service, fabrication shop, or shared machine — DXF is the universal fabrication format that professional shops are equipped to receive and process. SVG is a display and web format; DXF is the standard of physical manufacturing. Second, when the destination machine runs RDWorks on a Ruida controller — RDWorks handles DXF more reliably than SVG for production workflows. Third, when the file enters a CNC routing, plasma cutting, or CAM workflow — VCarve, Aspire, Fusion 360, SheetCAM, and Mach3 all use DXF as their primary import format. Fourth, when your SVG has geometry quality problems — open paths, duplicate lines, incorrect scaling — and you need a conversion pipeline that detects and repairs those problems as part of the process, delivering a verified output rather than passing unresolved issues downstream.

Use SVG when the file stays in LightBurn on your own machine. Convert to a properly prepared DXF when the file leaves your own software environment for any reason, or when you need geometry verification built into the process.

Six Conversion Failures That Are Invisible in Preview

Every one of the following problems passes a visual file check without raising any flag. They look correct in Illustrator, Inkscape, file explorer preview, and most DXF viewers. They only reveal themselves when the laser head starts moving. Each failure is rated below for how quickly it becomes apparent — some are obvious on the first job, others can survive undetected for weeks.

Failure 1 — Wrong dimensions. [Detected immediately] The DXF header contains a variable called $INSUNITS that declares the unit system the file's coordinates use. Per the official Autodesk DXF specification, value 4 means millimetres; value 1 means inches; value 0 means unitless or unspecified. When $INSUNITS is set to 0 or is missing from the header entirely, LightBurn cannot auto-detect the units and falls back to its user-configured DXF import unit preference — a dropdown in Edit > Settings under the File Settings tab. If that preference is set to a different unit than the file's actual coordinates, every dimension imports incorrectly. A confirmed real-world example from a 2024 LightBurn forum thread: a user's AutoCAD DXF had $INSUNITS set to 1 (inches) while all coordinates were drawn in millimetres. LightBurn interpreted the millimetre values as inch values and scaled them up by 25.4, turning a 200mm intended circle into a 5080mm import. Generic SVG-to-DXF converters routinely write $INSUNITS=0 or omit the variable entirely, making the importing software's fallback setting the only thing standing between correct and wildly incorrect dimensions. Always verify physical dimensions in your laser software immediately after every DXF import.

Failure 2 — Lines cut twice. [Detected after the run — material is already damaged] When two geometric entities occupy identical coordinates, the laser follows that path twice. On wood, a second pass deepens the kerf and chars the edges. On acrylic, cumulative heat from two passes causes cracking and discolouration. On thin materials it can burn through areas that should remain intact. Duplicate lines come from several well-documented sources. Fusion 360 produces them when the Auto Project feature is enabled — selecting a face automatically projects all its edges into a new sketch, and if the operator then manually projects the same geometry again, every line exists as two coincident entities. Per Autodesk's own support documentation, this is one of the most common causes of duplicate geometry in Fusion DXF exports. Other sources include SVG files where a stroke boundary and a fill boundary outline coincide, and copy-paste operations that create coincident geometry without the designer noticing. Two perfectly overlapping lines are visually indistinguishable from one in every preview tool — they can only be detected by mathematically comparing entity coordinates.

Failure 3 — Vertically mirrored output. [May go undetected for weeks on symmetric designs] SVG uses a coordinate system where Y increases downward from the top-left corner of the document. DXF uses a coordinate system where Y increases upward from the bottom-left. A converter that does not apply a Y-axis correction produces a DXF where the entire design is vertically mirrored. For symmetric shapes — circles, regular patterns, abstract geometry — this error is completely undetectable in design software and is only discovered after the job runs. For text, logos, portraits, and any asymmetric part it is a fatal error. The mathematical correction applied by a proper pipeline is: for each point, Y_dxf = document_height_mm − Y_svg.

Failure 4 — Curves that import incorrectly. [Detected after the run] DXF supports a native SPLINE entity for representing complex curves including NURBS and Bezier curves. It seems like the natural choice for curved geometry from SVG paths — but software support is inconsistent across tools and versions. LightBurn's SPLINE importer produced shape errors and 'dents' in curves prior to a major rewrite in version 1.5.00 (December 2023), which improved handling for SPLINE entities that are structurally equivalent to Bezier curves. However, it cannot correctly import all NURBS — only the Bezier-equivalent subset. RDWorks has received no equivalent improvement. VCarve, SheetCAM, Mach3, and most other tools in common use handle SPLINE entities poorly or not at all. The universally safe entity types are ARC, LINE, CIRCLE, and LWPOLYLINE — supported correctly by every version of every tool in common use. SVG Bezier curves should be converted to sequences of these entities rather than written as SPLINE.

Failure 5 — Everything on one layer. [Detected on import, but slow to fix manually] Laser machines execute different operations at different power and speed settings. A properly prepared DXF separates geometry into named layers corresponding to operation types — Cut, Score, Engrave — each assigned a colour that laser software reads to create distinct operation entries on import. Generic converters collapse all SVG structure onto a single DXF layer, typically the default layer '0' with no colour assignment. LightBurn imports this as a single operation with all geometry combined, requiring the operator to manually sort every entity by intended operation type before the job can run. For files with multiple operation types across many elements, this manual reconstruction takes longer than the original design work and introduces human error.

Failure 6 — Invisible geometry from unresolved SVG references. [May never be detected — missing geometry silently disappears] SVG files exported from Illustrator symbols, Figma components, and icon libraries commonly use <use> elements that reference geometry defined in a <defs> block elsewhere in the file. A converter that walks only the visible element tree without resolving these references silently discards all geometry defined via <use>. The result is a DXF that imports cleanly, passes every dimension check, and contains no errors — but is missing entire sections of the design. The cut runs, appears complete, and only when the finished part is examined does it become clear that a section was never cut. This failure is the hardest to diagnose because nothing in the file or in LightBurn flags it. The only protection is a pipeline that explicitly resolves all <use> references and compares entity counts between the parsed source and the written output.

What a Laser-Ready DXF Contains — Eight Properties and Why Each Matters

A laser-ready DXF is not simply a DXF that opens without errors — it is a file that has been explicitly prepared for machine operation. The six failure modes above each correspond to one or more missing properties. A complete list of eight properties defines what correct preparation looks like.

1. Correct units in the file header. $INSUNITS must be present and set to 4 in the DXF header. This declaration removes all ambiguity about what the file's coordinates mean. $INSUNITS=0 (unitless) is treated the same as a missing variable by most importing software — both force a fallback to the tool's user preference, which varies by operator. Always write 4 explicitly.

2. Named layers mapped to laser operations. Geometry is organised into named layers — Cut, Score, Engrave — each assigned a DXF ACI colour code: 1 (red) for Cut, 5 (blue) for Score, 7 (black in LightBurn) for Engrave. LightBurn reads these colours on import and creates a separate entry in the Cuts/Layers panel for each. This colour convention is widely adopted in the laser community, but it is community practice — not an enforced standard. Shops with established colour conventions should configure the mapping before conversion rather than accept any defaults.

3. Closed paths where cuts should be closed. Any shape the laser cuts out must form a geometrically closed loop — the last point must connect precisely to the first. A gap of even a fraction of a millimetre means the laser stops before completing the cut, leaving an uncut bridge that holds the part in the sheet. This gap is invisible at any normal zoom level in design software.

4. Zero duplicate or overlapping entities. Confirmed mathematically by comparing entity endpoints and sampled midpoints, not by visual inspection. A laser-ready DXF contains no coincident geometry on any layer.

5. No degenerate sub-threshold geometry. Conversion from Bezier curves to arc and line segments can produce zero-length segments and fragments under 0.01mm from floating-point rounding. Some controllers produce a burn mark at a zero-length location; others generate a motion error. All segments below 0.01mm that are not intentional fine detail should be removed.

6. Controller-compatible entity types — ARC, LINE, CIRCLE, LWPOLYLINE only. SPLINE entities are avoided because importing software handles them inconsistently depending on tool and version, as detailed above. Bezier curves are converted to sequences of arc and line entities using biarc approximation. The practical result: curves in the output are geometrically indistinguishable from the originals at any scale you would run on a machine. The mechanism: each Bezier segment is fitted with a pair of tangent-continuous circular arcs, subdivided recursively until deviation from the original is within 0.01mm. The output is universally importable by every laser, CNC, and CAM tool in common use.

7. Optimised entity order. Entities appear in the file in the order the laser should follow them: engrave first, then score, then cut. Within the cut layer, a point-in-polygon containment test identifies interior paths that must run before the exterior profile that would free the part from the sheet. If the exterior profile cuts first, the part shifts and all subsequent interior cuts are misaligned. LightBurn's built-in Optimise Cut Path feature refines this further at runtime — the DXF pre-ordering ensures correct behaviour on any software, including tools with no built-in optimiser.

8. Nominal geometry — no kerf compensation. A laser-ready DXF represents exact design dimensions with no paths widened or narrowed for kerf. Kerf varies by machine, lens, material, and cut speed — the file has no knowledge of these variables. A DXF with baked-in kerf compensation is correct for one specific machine-and-material combination and wrong for every other. Apply kerf in your laser software's cut settings per layer, not in the DXF.

Is This Standard Universal — or LightBurn-Specific?

The properties of a laser-ready DXF fall into two categories: those that are universally beneficial, and those that are convention-based.

The geometry properties are universal. Correct $INSUNITS declaration, zero duplicate lines, closed paths, no degenerate segments, biarc-fitted arc entities, correct Y-axis orientation — these make a DXF better for every piece of software that reads it. LightBurn, RDWorks, LaserGRBL, VCarve, Fusion 360, Aspire, SheetCAM, Mach3 — all benefit from clean geometry regardless of machine type or controller firmware. This is not a LightBurn-specific convention. It is simply correct, well-formed DXF.

The layer-naming and colour convention is community practice. The red-cut, blue-score, black-engrave system is widely followed and aligns with the visual defaults most LightBurn operators use. But no software enforces it. RDWorks uses its own layer numbering system. Some tools ignore DXF layer structure entirely and require manual assignment after import. A laser-ready DXF with correct layer structure is still a better file for any software — the layer information is additional structure that capable tools use, and that less capable tools safely ignore without any harm.

CNC routing and plasma cutting have identical geometry requirements. VCarve, Aspire, Fusion 360, SheetCAM, and Mach3 all suffer from the same unit, duplicate-line, open-path, and curve-entity problems that affect laser workflows. The geometry cleanup is the same. Only the layer convention differs — CNC workflows separate profile cuts, pocket operations, and drilling rather than cut/score/engrave. Configure the colour-to-layer mapping for your CAM software's expected layer structure and the same conversion pipeline produces an immediately usable file for any fabrication workflow.

What a Proper Conversion Pipeline Does — Nine Stages

A generic SVG-to-DXF converter performs a direct translation: paths become entities, coordinates are mapped, file is saved. It completes in seconds and produces a file that looks correct. A proper pipeline runs nine sequential stages, each addressing one category of structural problem that a direct export leaves unresolved. Understanding what each stage does explains why the output is different.

Stage 1 — SVG parsing, transform flattening, and reference resolution. An SVG is a hierarchical XML document with nested groups, each carrying its own coordinate transform. Every element's full transform chain — translate, scale, rotate, skewX, skewY, matrix — is multiplied together and applied directly to that element's coordinates, producing a flat list of paths in the document's root coordinate space. A converter that reads only top-level paths silently discards all geometry inside nested groups. Equally important: SVG files exported from Illustrator symbols, Figma components, and icon libraries commonly use <use> elements that reference geometry defined in a <defs> block. These references must be resolved explicitly — a converter that walks only the visible element tree silently drops this geometry, producing a file that imports cleanly but is missing entire sections of the design.

Stage 2 — Physical scale resolution and millimetre conversion. The SVG viewBox attribute and declared width and height are used together to derive a single millimetres-per-user-unit scaling factor. The viewBox is authoritative: divide the declared physical width in millimetres by the viewBox width in user units. This approach produces the correct scale regardless of which application created the file — Illustrator at 72 DPI, Inkscape prior to v0.92 at 90 DPI, or current tools at 96 DPI. Reading scale from the file's own attributes eliminates the DPI trap entirely. The Y-axis flip is applied at this stage: Y_dxf = document_height_mm − Y_svg.

Stage 3 — Fill and stroke resolution. Each path is classified for its laser role. Stroke-only paths become laser paths directly. Fill-only paths — the most common case for shapes drawn in Illustrator or Inkscape — have their boundary outline extracted. The operation colour that drives layer assignment comes from the stroke colour when present, or the fill colour otherwise. The fill rule (evenodd or nonzero, declared per-path in SVG) is preserved at this stage: compound paths with holes — letters with counters like O and B, rings, any nested closed shape — must retain their fill rule so that inner contours are treated as holes rather than filled islands. A pipeline that discards fill rule information will incorrectly fill shapes that should be hollow.

Stage 4 — Colour-to-layer mapping. Each path's resolved colour is mapped to a named laser layer using HSL hue ranges rather than exact hex values, because designers use many shades of red to mean 'cut'. A practical default: hue 340–360 or 0–20 maps to Cut; hue 200–260 maps to Score; lightness below 15% regardless of hue maps to Engrave. This mapping must be user-configurable — professional shops have colour conventions built into years of templates that no fixed default will match.

Stage 5 — Bezier curve conversion via biarc approximation. Cubic and quadratic Bezier curves from SVG paths are converted to sequences of circular arcs. The practical outcome is that curves in the DXF output are geometrically indistinguishable from the originals at any scale you would ever run on a machine. The mechanism: each Bezier segment is fitted with a pair of tangent-continuous circular arcs — a biarc — and subdivided recursively until the geometric deviation from the original curve is within 0.01mm. The output is ARC entities that are universally importable by every version of every tool in common use, and more compact than equivalent polyline approximations. SVG elliptical arc commands are first decomposed into cubic Bezier segments using the standard endpoint-to-centre parameterisation, then biarc-fitted.

Stage 6 — Geometry cleanup. Six operations run sequentially across the full entity list: remove all segments shorter than 0.01mm; detect and remove exact duplicate entities by comparing endpoints and midpoints within 0.001mm spatial tolerance; merge collinear consecutive segments in polylines; close nearly-closed paths where the gap between start and end is under 0.1mm; flag remaining open paths with a gap under 1mm in the processing report; remove geometrically identical overlapping closed paths. Partially overlapping paths — where two shapes share a segment without being exact clones — require boolean geometry processing and are flagged for operator attention rather than automatically modified.

Stage 7 — Cutting order optimisation. Entities are sorted for correct machine operation regardless of which software runs the job: engrave layer first, score second, cut last. Within the cut layer, a point-in-polygon containment test identifies interior paths that must precede the exterior profile. After inside-before-outside ordering, nearest-neighbour travel optimisation sequences remaining paths to minimise head travel. This pre-ordering is essential for any control software without a built-in path optimiser.

Stage 8 — DXF file assembly. Written in DXF R2010 format — the last format version with near-universal compatibility across all tools in common use, predating entity additions introduced in AutoCAD 2013. Note that the unit variable ($INSUNITS) and bounding box declarations used here are specified in the Autodesk DXF 2018 Reference, which defines the same header variables consistently across all modern format versions. The header declares $INSUNITS=4 and $EXTMIN/$EXTMAX bounding box values from actual geometry. Layer entries define Cut, Score, and Engrave with ACI colour codes 1, 5, and 7. Entities are written grouped by layer using LWPOLYLINE for closed polygonal shapes, ARC for arc segments, CIRCLE for complete circles, LINE for isolated straight segments. SPLINE entities are never written. No BLOCK or INSERT entities — all geometry is inline for maximum compatibility.

Stage 9 — Validation. The completed file is parsed back and verified: $INSUNITS present and equals 4, no invalid coordinate values, bounding box matches expected dimensions within 0.1mm, at least one entity on each populated layer, entity count matches the expected output from Stage 1 parsing. If validation fails, the error is returned with a specific description. A production pipeline never silently delivers a broken file.

Preparing Your SVG Before Conversion

A proper conversion pipeline corrects many structural problems automatically — but several source file properties determine outcome in ways no downstream processing can fix.

Colour-code your paths explicitly. The most reliable way to get correct layer assignments in the output DXF is to use consistent stroke colours in the SVG source. Red (#FF0000) for cut paths, blue (#0000FF) for score, and black (#000000) for engrave are the most widely adopted conventions and map directly to DXF ACI colours 1, 5, and 7. Paths with no colour or colours outside any mapped range will be defaulted to Cut with a processing report warning — review those warnings before the file goes anywhere near a machine.

Expand all live text to outlines. DXF has no font support. Text elements that have not been converted to outlines will either fail to import or arrive as unrecognised objects. In Illustrator: Type > Create Outlines. In Inkscape: Path > Object to Path. This step cannot be corrected in the DXF after conversion. When expanding text, also verify that letters with enclosed counters — O, B, A, P, R, D, Q — produce compound paths with holes rather than two filled shapes stacked. Most tools do this correctly by default, but if the inner shape (the hole of an O, for example) appears filled rather than hollow in your design application, the fill rule is wrong and will produce incorrect output.

Resolve all symbol references before export. If your SVG was created in Illustrator using symbols, or in Figma using components, expand or flatten all instances before exporting SVG. In Illustrator: Object > Expand Appearance, then Object > Flatten Transparency. In Figma: use Flatten Selection (Ctrl/Cmd+E) on all component instances before exporting. Unexpanded symbols export as <use> elements referencing <defs> geometry, which generic converters silently discard.

Remove embedded raster images. DXF is a pure geometry format. Raster images embedded in the SVG — photographs, textures, placed bitmaps — have no DXF representation and are silently dropped during conversion. If an embedded image contains geometry that needs to be preserved, trace it to vector paths before converting.

Know your SVG's origin application. Three tools use three different DPI conventions: the W3C standard and current Inkscape use 96 pixels per inch; Adobe Illustrator exports SVG at 72 pixels per inch; Inkscape prior to v0.92 (released 2017) exported at 90 pixels per inch. A conversion pipeline that derives physical scale from the file's own viewBox and declared dimensions handles all three correctly without any user action — the DPI of the originating application becomes irrelevant. A converter that applies a fixed DPI assumption will produce incorrect dimensions for files from at least two of the three sources. Verify dimensions after every import regardless of how the file was created.

Verify intended dimensions before upload. Open your SVG in your design application and confirm the document size matches the physical output you intend. If the SVG's declared dimensions are wrong — because the originating tool did not embed physical units correctly — correct them at the source before converting. A conversion pipeline cannot infer your intended physical size from incorrect source data.

Importing Into LightBurn and Verifying the File

Importing a laser-ready DXF into LightBurn correctly takes under two minutes when the verification steps are followed in order. Each step catches one specific failure category before it becomes a ruined workpiece.

Step 1 — Confirm dimensions. Immediately after import, check the bounding box in LightBurn's numeric position fields. Dimensions must match your intended physical design size. If the file is 25.4 times larger or smaller, $INSUNITS is set to the wrong unit or written as 0 — open the DXF in a text editor, locate $INSUNITS, change the value on the following line to 4 (millimetres) and re-import. If the scale error is approximately 0.75, 0.94, 1.33, or 1.07 times expected, the issue is a DPI mismatch in the SVG source — re-convert using a pipeline that reads scale from the file's viewBox rather than assuming a fixed DPI.

Step 2 — Confirm layer structure. In the Cuts/Layers panel, verify that each expected operation appears as a separate layer with the correct colour. If all geometry is on a single layer, the source SVG was not colour-coded or the converter collapsed layers — re-convert with correct colour-to-layer mapping. If an expected layer is absent, the corresponding paths either had no colour assignment or a colour outside the mapping range — check the processing report warnings.

Step 3 — Run Edit > Delete Duplicates. In LightBurn, go to Edit > Delete Duplicates (shortcut: Alt+D). This removes any duplicate entities that survived conversion. Run this on every imported DXF without exception — it takes one second and eliminates the most destructive laser quality failure.

Step 4 — Run Edit > Select Open Shapes. Open paths in the file are selected and highlighted. Review them: paths that should be closed outlines but are open indicate a gap the converter could not auto-close at the specified tolerance. Close them in LightBurn's node editor or return to the SVG source, fix the open path, and re-convert.

Step 5 — Verify operation types and settings per layer. For each layer, confirm the operation mode is correct: Line for cut and score paths, Fill or Line for engrave depending on intended effect. Verify power and speed are set explicitly for this job — LightBurn retains the last-used settings per colour across all projects indefinitely, so calibrated values from a job on different material will still be present. Verify them; never assume.

Step 6 — Run a framing pass. Press Frame with the laser disabled. The head traces the bounding box without firing, confirming physical position and size on the material. Run this before every job, without exception — it takes fifteen seconds and is the only check that catches incorrect positioning before material is consumed.

Sources and References

• Autodesk DXF 2018 Reference — $INSUNITS variable specification: value 0 = unitless, value 1 = inches, value 4 = millimetres
• LightBurn official documentation — Settings/Preferences page: Auto-detect units, configurable DXF import fallback unit dropdown, Auto-close tolerance (docs.lightburnsoftware.com)
• LightBurn Software Forum — confirmed $INSUNITS=1 causing 25.4× scale error (August 2024 thread)
• LightBurn Software Forum — official announcement of SPLINE importer rewrite in v1.5.00 (December 2023)
• Autodesk official support article — 'Getting duplicate lines when exporting DXF from Autodesk Fusion' (Auto Project as confirmed cause)
• SendCutSend Fusion 360 DXF export guide — confirmed workflow for avoiding duplicate geometry
• W3C SVG 1.1 specification — Y-axis coordinate system, top-left origin, Y increases downward
• Inkscape release notes — DPI change 90→96 at v0.92 (2017)
• ezdxf library documentation — DXF unit system, entity types