What is a native file?
A native file is a drawing or model held in the format its authoring application wrote, such as DWG for AutoCAD, DGN for MicroStation, or RVT for Revit, carrying the editable geometry and data that a PDF plot only pictures. Every other version of that drawing, the plot, the scan, the thumbnail, is derived from it.
A derived format is easy to read and easy to send, which is why most people meet a drawing as a PDF. The owner of the asset needs the file behind it, because that is the one the next engineer can work in.
Also called: native CAD file · source file · authoring format · Related term: rendition
The formats an owner actually receives.
Three native formats carry most of the engineering drawing record: DWG, DGN, and RVT. Each is written by its own authoring application, and each holds far more than the sheet it prints to.
Many engineering organisations and asset owners have made enormous investments in DWG, and hold it as both a knowledge store and a means of communication.
Read why CAD drawings move to the cloud- .dwgAutoCAD
The most common ongoing format for 2D engineering documentation, also read and written by BricsCAD, ZWCAD, DraftSight, and others.
- .dgnMicroStation
Bentley's format, long-established on large civil and infrastructure work, where the same attachment mechanism is called a reference file.
- .rvtRevit
The authoring format for a Revit building model, holding the parametric objects and the data attached to them.
Coordinate geometry you can measure, snap to, and edit.
A picture of that geometry, fixed at one scale and one sheet.
Layers, blocks, attributes, and model space kept separate from paper space.
Flattened to a page, with the structure discarded on the way out.
Live xrefs and reference attachments to the other drawings it depends on.
The references are printed in, and the files behind them are no longer identified.
Title-block attributes readable as data, so a register can fill itself.
Text printed on the sheet, reachable only through OCR.
The next project starts from the drawing.
The next project starts by redrawing it.
A native drawing is often more than one file.
AutoCAD attaches other drawings as external references, or xrefs, and MicroStation attaches them as reference files. A site plan may reference a survey, a services layout, and a boundary drawing, so the parent file is a shell that resolves against several others.
The dependency is a strength during design, because a change to the common file flows through to everything that references it. It becomes a liability at handover. A transmittal that lists only the parent drawings does not identify the referenced files, so the linked dependencies go missing without anyone noticing, and the gap surfaces when the drawings are needed for operations and maintenance.
Keep the native, and serve the rendition.
Lunr holds the native file as the controlled record and generates the readable copy from it, so the two never disagree. Drawings open in the browser without a CAD licence, and the file underneath stays the authoring format the next engineer needs.
- Hold DWG, DGN, RVT, PDF, and IFC in one register, each under revision control with its own history.
- A PDF rendition is generated in the background, so anyone can view a drawing in the browser without a CAD licence.
- Markups sit on the rendition, so the released native file itself is never altered by a reviewer.
- XRef validation runs on submission, so a package with a missing reference is rejected before it is booked in.
- Title-block attributes are read from the drawing and applied as metadata, so nobody retypes the drawing number.
- Read and write DWG and DGN through the connector APIs, so authored files and the controlled record stay in step.
- Export all documents and metadata at any time, so the natives stay yours.
dwg · dgn · rvt · ifc · pdf rendition · xref validation · title-block attributes · export anytime
See how a package is validated at handoverKeep reading.
Why linked dependencies go undetected at handover, and how to check for them before they do.
How DGN reference files organise a model by discipline, and what that means for the record.
The panel whose attributes make a native drawing self-describing to the register.
Where DWG, DGN, RVT, and PDF sit together under revision control and open in the browser.
Questions about native files.
- What is the difference between a native file and a PDF?
- The native file is what the authoring application wrote, so it holds coordinate geometry, layers, blocks, title-block attributes, and links to the drawings it references. A PDF is a plot taken from that file: a fixed picture of one sheet at one scale, with the structure flattened out. You can read a PDF, print it, and mark it up. You cannot edit it as geometry, resolve its references, or read its attributes as data.
- Why should an asset owner receive native files at handover?
- Because everything after handover starts from the drawing. Modifications, extensions, condition assessments, and the next capital project all need geometry that can be edited and measured, and a PDF-only archive forces each of them to begin by redrawing. Native files also carry title-block attributes that a document control system can read into metadata, so the register fills itself instead of being retyped. Take the natives and their renditions together, and hold both under the same document number and revision.
- What are xrefs, and why do they go missing?
- An xref is an external reference: a drawing attached into another drawing so a change to the common file flows through to everything that references it. MicroStation calls the same idea a reference file. The dependency is useful during design and becomes a liability at handover, because a transmittal that lists only the parent drawings does not identify the referenced files. The parent arrives, the reference does not, and nothing notices until someone opens the drawing years later. Checking for missing references at the point of submission is the only practical time to catch it.
- Is IFC a native file?
- No. IFC is an open, vendor-neutral exchange schema standardised as ISO 16739-1, exported from an authoring model rather than written by the authoring application as its working format. That makes it a strong archival companion, because it is readable without the vendor's software, and a poor substitute for the native model, because the parametric behaviour and application-specific data do not survive the export. Archive both.
- What is the risk of a PDF-only archive?
- You end up owning a picture of the asset rather than the asset's drawings. Scales and coordinates cannot be verified, scanned sheets carry text only as pixels until OCR reads them, and every future change carries the cost of rebuilding geometry that already existed. The natives usually still exist somewhere, on a consultant's server or a decommissioned drive, but the right to them and the ability to find them both expire quietly.
Take the natives, and the references behind them.
Book a walkthrough and watch Lunr validate xrefs on submission, read the title block into metadata, and open a DWG in the browser without a CAD licence.
10M+ documents under management · Hosted in Australia and the US · SAML · Full audit trail · Export anytime
- entity
- Lunr Labs Pty Ltd
- location
- Melbourne AU
- workspace
- documents.lunr.app
- rev
- 2026