GDS to DXF converter

Q: What drawing unit does the exported DXF use?

One drawing unit is exactly 1 nanometre, declared with `$INSUNITS = 12` and `$MEASUREMENT = 1` for metric. GDS world coordinates are integer nanometres, so every coordinate is written exactly. A reader that ignores `$INSUNITS` applies its own unit instead, so the drawing opens at the wrong scale with correct geometry. KLayout 0.30.11 is one such reader (1 unit = 1 µm unless you change its DXF unit), and the section on CAD tools below says what to set.

Turn a chip or mask layout saved as GDS into a DXF drawing that AutoCAD and other CAD programs can open. Drop the file on the converter below and download the DXF: it all happens in your browser, and nothing is uploaded. Each layer keeps its own DXF layer, each cell becomes a reusable block, and sizes stay exact, in nanometres.

Under the hood, GDSII-to-DXF conversion takes a hierarchical mask layout (integer coordinates, numbered (layer, datatype) pairs, SREF and AREF placements) and writes it as a DXF R2000 drawing. The file is read, converted and written locally; there is no server to upload it to.

How to convert GDSII to DXF

Drop your .gds or .gdsii file onto the converter on this page.
Pick DXF as the target format. No options are needed: the unit mapping, layer naming and entity choices below are fixed so the output is predictable.
Download the .dxf file. Open it in your CAD tool, or in the free Glyph editor if you want to compare it against the source layout first.

Will the DXF open in my CAD tool?

It should: the file uses an old, widely read version of DXF and only three simple kinds of object (outlines, placed blocks and text). If it opens at the wrong size, the drawing unit is the setting to check (point 1 below).

In detail, it is an ASCII DXF of version R2000 ($ACADVER = AC1015) holding only three entity types, LWPOLYLINE, INSERT and TEXT, with each cell as a BLOCK. We checked a converted file on 2026-11-01 with ezdxf 1.4.4, which read it as R2000 with no audit errors and no repairs, and with the DXF reader of KLayout 0.30.11. We have not tested other CAD programs. Three things decide whether it opens at the size you expect:

The unit. One drawing unit is one nanometre, and the file says so ($INSUNITS = 12, nanometres), so a CAD program that reads that setting shows the true size. KLayout 0.30.11's DXF reader did not use it in our test: it read 1 unit as 1 µm, its default, until we changed the DXF unit in its reader options, so set that to 0.001 µm for this file. In the editor, File → Export ▸ Export DXF… writes the unit you work in instead, nanometres, micrometres or millimetres ($INSUNITS 12, 13 or 4), and a micrometre file opens at the true size in KLayout's default setting.
The layer names. Each (layer, datatype) pair is a DXF layer named L1D0, or L1D0_METAL when the layer has a name of its own. A GDS file has no layer-name record, so a file converted here gets the plain form. KLayout reads both forms back to the same layer and datatype numbers, with the name.
The curves. There are none to convert: a circle in the layout is already a polygon, and it reaches the DXF as a closed LWPOLYLINE.

If a CAD program refuses the file, open it in the Glyph editor to confirm the geometry is there, then try re-saving it from a program that can read it. DXF vs GDSII explains what each format can hold.

What survives and what changes

Aspect	What happens
Entities written	Only three kinds: outlines, placed blocks and text (LWPOLYLINE, INSERT and TEXT). A boundary or box becomes a closed LWPOLYLINE; a path becomes an open LWPOLYLINE.
Curves	None are emitted. GDSII has no arc primitive, so a circle or curved edge is already a many-sided polygon in the source and stays a polyline in the output.
Units	Nanometres: 1 drawing unit = 1 nm, so every coordinate is exact rather than a rounded micron fraction. The file declares it as `$INSUNITS = 12` with `$MEASUREMENT = 1`.
Layer names	The `(layer, datatype)` pair is always encoded in the DXF layer name: `L1D0` for a layer with no name of its own, `L1D0_METAL` for a layer named METAL. Names are sanitised to characters AutoCAD accepts and de-duplicated, so `1/0` and `1/4` can never merge.
Layer colours	Written as the nearest AutoCAD Color Index — the only colour field a DXF R2000 LAYER record defines — plus the exact RGB as a true-colour value (group 420), which tools that read it (Glyph among them) show exactly. A hidden Glyph layer is written with a negative ACI, DXF's "layer is off", never dropped.
Hierarchy	Each cell becomes a BLOCK. An SREF becomes an INSERT carrying magnification, rotation and mirroring.
Axis-aligned arrays	An AREF whose lattice is axis-aligned, positive-stepped and unrotated becomes a single INSERT with DXF's column/row array groups (70/71/44/45) — one entity, however large the array.
Other arrays	An AREF that cannot use DXF's orthogonal form expands instance by instance up to 20 000 instances. Past that only the four corner instances are written, and a `999` comment in the file says so.
Paths	A widened path becomes a constant-width LWPOLYLINE (group 43). The GDS end-cap style (`pathType`) has no DXF equivalent and is lost — the result is always flush-capped.
Text	Written as a plain TEXT entity in the `Standard` style at the GDS text size, positioned by the resolved anchor. Font, letter spacing and justification collapse into that offset.
Not exported	Construction shapes, bitmaps and persistent dimension annotations are excluded, the same contract as every other Glyph writer.
Damaged input	A truncated or corrupt `.gds` is reported, never silently converted as a partial file — the reader warns on a missing `ENDLIB`, a corrupt record with its byte offset, unconsumed tail bytes, and dropped `NODE` elements.
Round trip	Re-importing a DXF that Glyph wrote restores geometry, hierarchy, each (layer, datatype) pair, layer names and exact colours — Glyph encodes the pair in every DXF layer name and marks the file as its own. A DXF re-saved by another CAD tool can lose that mark, and then the encoded names come back literally. Keep the `.gds` as your master file.
Validation	Output is judged by ezdxf, never by Glyph's own DXF reader, when the writer changes. A lossy writer round-trips cleanly against a lossy reader, so the oracle has to be an independent implementation.

Why DXF is a lossy destination for mask data

DXF was built for general drafting: named layers, native arcs, floating-point coordinates in a user-chosen unit. GDSII was built for photomask and IC layout: numbered (layer, datatype) pairs, closed filled polygons, integer database units. Converting downward means giving up the datatype dimension (recovered here only as a naming convention), the end-cap model, and true layer colour.

That is a fair trade when the destination is a CAD tool, a drawing office, or a lithography flow that reads DXF — and a bad one if you are archiving. For the full side-by-side, see DXF vs GDSII. For the source format's record structure, see the GDSII file format reference.

If your goal is a figure for a paper or a slide rather than a CAD handoff, GDSII to SVG is the better target — see also the publication figures guide.

Open it in the editor

To check layer mapping, hierarchy or geometry before you hand the DXF on, open the source file in the free Glyph editor — nothing to install, and your files never leave your browser. See Open & save and Layers.

Glyph is made by NANYTE. For where a finished layout goes next, read NANYTE's maskless lithography overview.

Frequently asked questions

What drawing unit does the exported DXF use?

One drawing unit is exactly 1 nanometre, declared with $INSUNITS = 12 and $MEASUREMENT = 1 for metric. GDS world coordinates are integer nanometres, so every coordinate is written exactly. A reader that ignores $INSUNITS applies its own unit instead, so the drawing opens at the wrong scale with correct geometry. KLayout 0.30.11 is one such reader (1 unit = 1 µm unless you change its DXF unit), and the section on CAD tools below says what to set.

How is the GDS datatype represented in DXF?

DXF has no datatype concept, so the pair is encoded in the layer name as L1D0 (layer 1, datatype 0). Without that convention, layer 1/0 and layer 1/4 would silently merge into one DXF layer.

Does the cell hierarchy survive?

Yes. Each GDS cell becomes a DXF BLOCK, an SREF becomes an INSERT carrying magnification, rotation and mirroring, and an axis-aligned AREF becomes a DXF orthogonal array on one INSERT.

Will the exported DXF contain arcs and circles?

No. GDSII has no arc primitive, so anything curved is already a polygon by the time it reaches the writer. The writer emits only TEXT, LWPOLYLINE and INSERT entities, which is what makes the output predictable for mask and lithography tooling.

Is my GDSII file uploaded anywhere?

No. The conversion runs entirely in your browser using the same writer as the Glyph editor. There is no server to upload to, and your design data never leaves your machine.

Is there a file size limit?

The conversion runs inside your browser tab, so your machine's memory is the real ceiling. The converter checks the file size before parsing, warns above roughly 50 MB and declines files beyond roughly 200 MB rather than risking an out-of-memory crash.

What happens if my GDSII file is truncated or corrupt?

It is reported, not silently converted as a partial file. The reader warns on a missing ENDLIB record, on a corrupt record together with its byte offset, on unconsumed bytes at the end of the file, and on dropped NODE elements, so a short file can never look like a whole one.

How is the DXF output checked?

The DXF writer is validated against ezdxf, a Python implementation that shares no code with Glyph, by a validator the project runs whenever the writer changes. Its auditor runs over each fixture with repairs treated as failures, structural expectations are hand-written so they cannot inherit the writer's bugs, and planted negative controls must each fail.