DGN File Documentation

---

Technical details

Feature	Value
Full name	MicroStation Design File
File extension	.dgn
MIME type	image/vnd.dgn; application/octet-stream
Format type	Binary 2D/3D CAD design file (element-based)
Developer	Bentley Systems (format roots in Intergraph IGDS)
Introduced	Intergraph IGDS, early 1980s; MicroStation since 1985; V8 DGN in 2000
Versions	V7 ISFF (through MicroStation v7); V8 (MicroStation V8, 2000 onward)
Standard / spec	Intergraph Standard File Formats (ISFF); V8 is proprietary, documented via ODA
Open standard	No — partial third-party support via the Open Design Alliance
Byte order	Little-endian (16-bit words in V7 ISFF)
Magic number (V8)	D0 CF 11 E0 A1 B1 1A E1 (OLE2 / Compound File)
Magic number (V7)	ISFF element header at offset 0; no OLE2 signature
Container / base (V8)	Microsoft OLE2 / Compound File Binary (CFB)
Element header (V7)	18 words (36 bytes): type, level, range block, words-to-follow
Coordinates	Integers in UORs (Units of Resolution)
Organisation	Elements on levels (layers); one or more models per V8 file
Related extensions	.dwg, .dxf, .cel, .rsc, .dgnlib
Specification URL	opendesign.com/products/drawings

What is a DGN file?

DGN is short for “design”, and a MicroStation Design File is the native CAD format of Bentley Systems’ MicroStation. It stores an engineering drawing as a set of discrete graphic elements — lines, arcs, shapes, text and reusable cells — along with the settings that describe how those elements are drawn and measured. The format did not begin at Bentley. It grew out of Intergraph’s Interactive Graphics Design System (IGDS) in the early 1980s, and Bentley has developed MicroStation on top of it since 1985. DGN is heavily used in civil and infrastructure work: roads, bridges, rail, utilities and large architectural projects, where government transportation departments often mandate it as a deliverable. Its MIME type is image/vnd.dgn.

There are two distinct on-disk generations of the format, and they are not the same file at the byte level. The older format, retroactively called V7, is the Intergraph Standard File Format (ISFF): a fixed-record binary layout used through MicroStation v7. The newer format, V8, arrived with MicroStation V8 in 2000 and stores the same kind of element data inside a Microsoft OLE2 compound-file container. Everything below explains both: how a V7 element record is laid out word by word, and how V8 wraps that model in a compound document. The closest sibling format is AutoCAD’s DWG, which is the usual interchange target.

V7 ISFF and V8: two generations, one extension

The same .dgn extension covers two formats with different file structures, so it helps to be precise about which one you have. V7 DGN is the Intergraph Standard File Format, published by Intergraph in the late 1980s and used unchanged by MicroStation for over a decade. It is a flat, element-based binary file: a sequence of records, each describing one graphic or control element, with no container wrapping them. Because it inherited 1980s constraints, V7 caps design coordinates at 32-bit integers and limits levels to 63.

V8 DGN, introduced with MicroStation V8 in 2000, keeps the element concept but rebuilds the file as a Microsoft OLE2 / Compound File Binary (CFB) document. That change removed old size ceilings, raised the level count into the thousands, allowed multiple models inside one file, and added design history and much tighter DWG interoperability. The practical consequence for anyone inspecting bytes: a V8 DGN starts with the OLE2 magic D0 CF 11 E0 A1 B1 1A E1, while a V7 DGN starts directly with an element header and carries no such signature. MicroStation opens V7 files and saves them as V8 (and can save back to V7 for legacy tools), so “upgrading” is a same-extension format change, not a conversion to a different file type.

The element record: a 36-byte header

The heart of the format, in both generations, is the element. Every graphic object and every control block in a V7 file is one element, and each element begins with a fixed header of 18 16-bit words — 36 bytes — stored little-endian. The header tells a reader what the element is, which level it lives on, how many words it occupies, and the bounding box it covers, all before any type-specific data.

DGN (V7 ISFF) element header — 18 words, 36 bytes, little-endian

word 0   : element type (7 bits) | level (6 bits) | complex/deleted bits
word 1   : words to follow (length of the rest of the element)
word 2-13: range block — six 32-bit signed integers, in UORs:
             Xlow, Ylow, Zlow, Xhigh, Yhigh, Zhigh   (min/max corner)
word 14+ : element-specific data (coordinates, symbology, text, ...)

Word 0 packs the element type and the level together with status bits. The type is a small integer that names the element (see the next section); the level is 0–63 in V7. Word 1 is the crucial words-to-follow count: it gives the length of the remainder of the element, so a parser that does not understand a given type can still skip it exactly and continue. Words 2 through 13 hold the range block, the element’s axis-aligned bounding box as six 32-bit signed integers (minimum then maximum X, Y and Z). Those coordinates are not millimetres or feet; they are integer Units of Resolution, described further down. After the header comes the element’s own payload: vertex coordinates for a line, the character data for text, a colour/weight/style symbology block, and any attribute linkages.

Element types: lines, shapes, text and cells

The 7-bit type field in word 0 selects what kind of element the record is. The set is small and stable, which is why libraries like the Open Design Alliance’s Drawings SDK and GDAL can walk an unknown DGN reliably. The common graphic types are:

Type code	Element
1	Cell library header
2	Cell header (an instance of a reusable block)
3	Line (two endpoints)
4	Line string (connected vertices)
6	Shape (closed polygon)
7	Text node
11	Curve
15	Ellipse
16	Arc
17	Text
21	B-spline curve

A cell is DGN’s reusable block: a named group of elements (a bolt, a tree symbol, a manhole) defined once and placed many times. Cell definitions live in cell libraries, historically separate .cel files, and each placement in the drawing is a cell header (type 2) followed by the component elements. Text elements (type 17) and text nodes (type 7) carry the string plus font, height and justification. Complex chains and complex shapes group several elements under one header, using the complex bit in word 0 to mark the members that belong together.

Levels and symbology

DGN organises elements onto levels, which are its equivalent of the layers in DWG and DXF. A level groups related content — centrelines, dimensions, annotation — so it can be shown, hidden, locked or printed as a unit. In V7 ISFF the level is the 6-bit field in word 0, giving a hard limit of 64 levels (0–63) that engineers frequently bumped against. V8 removed that ceiling: levels became named, effectively unlimited, and stored in a level table rather than a packed bitfield.

Alongside its level, each element carries a symbology block: colour index, line weight (thickness) and line style (solid, dashed, and custom styles defined in a resource file). Custom line styles and text fonts live in resource files with the .rsc extension, which is one reason a DGN can look different on a machine that lacks the sender’s resources. This symbology-plus-level model is also where DGN-to-DWG translation gets fiddly, because DGN levels map to DWG layers and DGN cells map to DWG blocks, but the correspondence is not always one to one.

UORs and working units: the integer coordinate system

DGN does not store coordinates as floating-point measurements. It stores them as integers in Units of Resolution (UORs), and a small hierarchy of definitions converts those integers into real-world distances. The design plane is a fixed integer grid; every vertex, and every corner of every element’s range block, is a UOR count on that grid. This choice keeps geometry exact and avoids floating-point drift when elements are moved or snapped together.

The mapping to physical units is the working units definition: a master unit (say a metre or a foot), a number of sub-units per master unit (for example millimetres per metre), and a number of UORs per sub-unit. Multiply those together and you get UORs per master unit, the scale factor that turns an integer coordinate into a measurement. In V7 the whole design plane is bounded by the 32-bit integer range, which is why old files can hit coordinate limits; V8’s larger integers and 64-bit-friendly container widen that plane substantially. When a DGN is converted to a floating-point format like DWG, this UOR grid is resolved to real coordinates, and rounding at that step is one source of translation differences.

The TCB: the design file’s control block

A V7 DGN opens with header elements, not drawing geometry. The first records are control elements of types 8, 9 and 10, and the key one is the Type Control Block (TCB), the type 9 element. The TCB is the design file’s master header: it holds the global settings that the rest of the file assumes, including the working-units definition (master units, sub-units and UORs per unit), the active level, the current colour, weight and style, the global origin of the design plane, and view configuration. A reader parses the TCB first because it needs the UOR-to-units scale before any coordinate in the file means anything.

In V8 the same information is preserved but lives inside the compound-file container rather than as a bare leading record. The model header for each model plays the equivalent role of the classic TCB, carrying that model’s working units, origin and active settings. Because a V8 file can hold several models, each design or sheet model has its own header describing its own coordinate context.

The V8 OLE2 / compound-file container

A V8 DGN is a Microsoft OLE2 Compound File Binary document. That is the same container technology behind legacy .doc and .xls files, which is why all three begin with the identical 8-byte signature D0 CF 11 E0 A1 B1 1A E1 at offset 0. A compound file is a small file system inside a file: it has a header, a FAT-like sector allocation table, and a tree of storages (folders) and streams (files). MicroStation stores the design’s models, level tables, element data, and metadata as named streams within that internal directory.

V8 DGN = OLE2 / CFB compound file

offset 0 : D0 CF 11 E0 A1 B1 1A E1   compound-file signature (8 bytes)
           ... CFB header: sector size, FAT/DIFAT, directory start ...
           +-- Storage (root)
                +-- Stream: model data (elements, still element-based)
                +-- Stream: level / symbology tables
                +-- Stream: metadata, properties, design history
                +-- ... reference and settings streams ...

The important nuance: wrapping the file in OLE2 did not throw away the element model. Inside those streams, the drawing is still a sequence of elements with the same conceptual structure as V7, just freed from the old 16-bit-word packing and 64-level limits. The signature is a container marker, not a DGN marker, so tools identify a V8 DGN by combining the extension with the presence of the DGN-specific streams rather than trusting the magic bytes alone. One security footnote follows from the shared container: OLE2 is also the wrapper of macro-bearing Office documents, but a DGN carries CAD elements, not Office VBA macros.

Models and reference attachments

Two features define how DGN files are assembled into real projects: models and references. A model is a self-contained container of elements with its own coordinate context. V7 files hold a single model; a V8 file can hold many, split into design models (the drawing at real-world scale) and sheet models (a printable layout that arranges views of design models onto a page). Each model has its own header carrying its working units and origin.

A reference attachment links one DGN to another so the referenced file’s elements appear in the host without being copied into it. This is how large projects are federated: a base survey, a road-design DGN and a drainage DGN can each be maintained separately, then attached together so a plan sheet shows all of them live. References can point at other DGN files or at DWG files, and each attachment stores the transform (offset, scale and rotation) that positions the referenced geometry in the host’s coordinate system. Because references are links rather than embedded copies, moving a DGN without its attached files leaves empty frames where the referenced content should be, a common cause of “missing” drawing content when a file is shared on its own.

References

• Bentley Systems — MicroStation (native DGN application)
• Open Design Alliance — Drawings SDK (DGN/DWG read/write libraries)
• Bentley Systems — Bentley View (free DGN/DWG viewer)

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.