Convert GDSII to OASIS
GDSII-to-OASIS conversion re-encodes a mask layout into OASIS, the newer SEMI P39 layout stream format, which stores the same hierarchy of cells, polygons, paths and labels using compact variable-length numbers, built-in repetition records and modal state. Hierarchy and arrays are preserved; the file gets smaller. The conversion runs entirely inside your browser — the file is read, converted and written locally, and there is no server to upload it to.
How to convert GDSII to OASIS
- Drop your
.gdsor.gdsiifile onto the converter on this page. - Pick OASIS as the target format. Output is CBLOCK-compressed by default.
- Download the
.oasfile. Open it in the free Glyph editor if you want to confirm cells and arrays came across as expected.
What survives and what changes
| Aspect | What happens |
|---|---|
| Hierarchy | Preserved. Cells and placements map straight across, nothing is flattened. |
| Cell order | The writer walks the document's recorded cell order rather than raw key order. GDSII has no top-cell record and every reader infers one, so a reordered file can silently change which cell a downstream tool treats as the top. |
| Arrays | Every uniform AREF becomes one record, whatever the direction or sign of its steps: types 1/2/3 for an axis-aligned positive lattice, type 8 for an arbitrary two-vector lattice, type 9 for a one-dimensional one. |
| Array edge case | A one-column, multi-row array on a non-axis-aligned lattice has no OASIS form that preserves the row/column labelling, so it rides type 9 and returns with rows and columns swapped. Instance positions are exact. |
| Out-of-range steps | A step vector beyond the encodable delta range falls back to expanded placements, capped — and it warns twice: once for the fallback, once to say what is missing from the file. Nothing is dropped silently. |
| Path end caps | The one geometry loss. OASIS has no round-cap concept, so a GDS path with round caps is written with a square extension instead. |
| Text | Size, font and justification are written as element properties with the standard bit set — the form that survives to other tools. A default-sized label with no font or justification emits no property record at all, so ordinary files stay compact. |
| Units | The START record's unit is derived from the document's precision, not from the GDSII user-unit field. Trusting the user unit would scale the whole design by 1000x on documents where it is only nominally set. |
| Compression | CBLOCK, raw DEFLATE. The END record is padded to the fixed size real readers require. |
| Strict mode | Non-strict only: no name tables with byte offsets, no cell-offset properties, no strict-mode trailer. A reader scans for the name records instead of seeking to them. |
| Point lists | Always written as general deltas rather than the more compact Manhattan or octangular forms. A misclassification there would not fail to parse — it would silently draw a different polygon — so there is exactly one code path. |
| 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. |
| Not save-in-place | .oas is deliberately not a save-in-place format in the editor, because of the path-cap loss above. Format changes stay explicit. |
| Validation | Output is judged by KLayout and gdstk, implementations that share no code with Glyph, against hand-written expectations. Three negative controls must fail on every passing fixture; a control that cannot apply is reported as skipped, never counted as a pass. |
Why convert GDSII to OASIS
OASIS was designed to store the same geometry as GDSII in dramatically smaller files. Rather than a fixed-width integer per coordinate, it uses compact variable-length numbers, a richer set of built-in repetition and shape descriptions, and modal state that lets a writer omit any value unchanged from the previous record. On dense, hierarchical mask data the saving is large, which is the format's whole reason for existing.
The trade is adoption: GDSII remains the default handoff between design tools and mask shops, so the practical pattern is to archive and exchange in whichever format your counterparty reads, and convert on demand. For the full comparison — origins, file size, compression, tool support — see GDSII vs OASIS. Going the other way is OASIS to GDSII.
Open it in the editor
To confirm cells, arrays and layer assignments after converting, open the file in the free Glyph editor — nothing to install, and your files never leave your browser. See Cells & hierarchy and SREF & AREF.
Glyph is made by NANYTE. For where a finished layout goes next, read NANYTE's maskless lithography overview.
Frequently asked questions
Does the cell hierarchy survive GDSII to OASIS conversion?
Yes. Both formats describe the same hierarchical model, so cells and placements map straight across and nothing is flattened. Cells are written in the source document's own order, so a reader infers the same top cell as before the conversion.
How are arrays written?
Every uniform AREF becomes exactly one record — repetition types 1, 2 and 3 for an axis-aligned positive lattice, type 8 for an arbitrary two-vector lattice, and type 9 for a one-dimensional one. A wafer-scale array therefore costs one record, not one record per instance.
What is the one geometry loss?
OASIS has no round path end-cap concept, so a GDS path with round caps is written with a square extension instead. That is the single documented geometry loss in the writer, and it changes the shape of the cap only.
Do text labels keep their size, font and justification?
Yes. An OASIS TEXT record has no field for any of the three, so they are written as element properties with the standard bit set, which is what makes them survive to other tools. A default-sized label with no font or justification emits no property record at all.
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.
Is the output checked against another implementation?
Yes. Writer output is judged by KLayout and gdstk, two implementations that share no code with Glyph, never by Glyph's own reader — a symmetric misreading would round-trip cleanly through our own code and prove nothing. Three negative controls must each fail on every passing fixture.
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.