DWG Insertion Units — Because Apparently Xrefs Needed Another Way to Waste Your Day Fighting Chaos

There are plenty of Civil 3D template settings that can make drawings annoying over time.

Bad layers. Bad styles. Zombie label styles from 2014. Surface styles named FINAL_FINAL_USE_THIS_ONE.

Normal CAD archaeology.

But one setting deserves its own special place in the production dumpster fire:

Insertion units.

And before this turns into another “Civil 3D units” conversation, let’s get one thing straight:

Insertion units are not the same thing as Civil 3D drawing units.

Civil 3D drawing units live in Civil 3D’s drawing settings.

Insertion units are an AutoCAD setting that tells the drawing how to handle outside content when it gets inserted or attached. That outside content can include:

• Xrefs

• blocks

• images

• inserted DWG files

The AutoCAD variable behind this is called:

INSUNITS

That setting is saved inside the drawing. So if it is wrong in your template, congratulations: every new drawing made from that template may inherit the same little gremlin.

That is where the fun begins.

And by “fun,” I mean:

“Why is this base file twelve times too big and who messed with the template?”

Insertion Units Are Not Civil 3D Drawing Units

This needs to be said LOUDLY:

Civil 3D drawing units and AutoCAD insertion units are two different things.

Civil 3D drawing units help Civil 3D understand the drawing environment.

Insertion units help AutoCAD decide how big outside content should be when it gets inserted or attached.

That means INSUNITS matters for things like:

• Xrefs

• inserted blocks

• raster images

• inserted DWG content

It is not the same thing as:

• the Civil 3D coordinate system

• Civil 3D drawing units

• surface units

• label precision

• whatever that one old template has been quietly doing since 2016

Now, because this is Civil 3D and nothing is simple, these settings can still interact in some workflows. For example, Civil 3D’s Set AutoCAD variables to match option can affect AutoCAD variables like INSUNITS.

So no, they are not the same setting.

But yes, one can still step on the other’s toes.

Very normal. Very relaxing. I swear!..lol

“Insertion Unit Precision” Is Usually the Wrong Phrase

People sometimes say:

“The insertion unit precision is different between the drawings.”

That usually mixes up two different ideas.

Setting	What It Means
Decimal precision	How many decimal places you see
Insertion units	What unit AutoCAD assumes when outside content is inserted

Those are not the same thing.

If one drawing shows four decimals and another shows two decimals, that is a display precision difference.

Example:

Actual Value	2 Decimal Display	4 Decimal Display
100.1234	100.12	100.1234

That changes what you see.

It does not automatically make AutoCAD treat feet as inches.

Insertion units are unit definitions, such as:

• Unitless

• Inches

• Feet

• US Survey Feet

• Millimeters

• Meters

Precision controls the number of digits you see.

Insertion units control how AutoCAD interprets the size of outside content.

Tiny difference. Huge mess.

Example 1: Host Drawing Is Feet, Xref Is Inches

This is the classic:

“Why is my Xref twelve times wrong?”

Let’s say your sheet drawing is set like this:

INSUNITS = Feet

But the Xref is set like this:

INSUNITS = Inches

AutoCAD sees those as different units.

Since there are 12 inches in a foot, the Xref can come in 12 times too big or 12 times too small, depending on how the files are being attached.

The Xref did not randomly break.

AutoCAD was doing what the drawings told it to do.

Which in production work makes life stressful.

Example 2: Same Xref, Different Drawing, Different Result

This is the one that makes support tickets sound haunted.

A user attaches the same Xref into Drawing A.

It looks fine.

Then they attach the same Xref into Drawing B.

It comes in wrong.

The Xref did not change.

The host (file you are xrefing something into) drawing changed.

Example:

File	Insertion Units
Xref source/base file	Feet
Drawing A	Feet
Drawing B	US Survey Feet

In Drawing A, the units match.

In Drawing B, they do not.

So the same Xref can behave differently depending on the drawing it is attached to.

This is why templates matter.

If one template says Feet, another says US Survey Feet, and another says Unitless, users will start blaming:

• Xrefs

• Civil 3D

• consultants

• lunar cycles

• each other

The actual culprit may be the template quietly carrying the wrong insertion-unit setting.

Templates: somehow both helpful and capable of betrayal.

Example 3: One File Is Unitless

Unitless drawings are where AutoCAD basically says:

“I’ll just guess what you meant.”

Which is exactly the level of confidence nobody asked for.

If a drawing has:

INSUNITS = 0

that means the drawing is unitless or unspecified.

That does not always mean the drawing is wrong. Unitless can be useful in some workflows.

But it should be intentional.

It should not be there because nobody checked the template.

Example:

File	Intended Unit	Insertion Units
Survey base	Feet	Unitless
Civil 3D host	Feet	Feet
Old host drawing	Feet	Inches

The survey base may be drawn correctly.

But when it gets attached or inserted, AutoCAD may have to rely on default assumptions because the file itself does not clearly say what unit it uses.

That is not a standard.

That is a shrug saved as a DWT.

More info on why I believe Unitless is a poor plan for Civil 3D work can be found here: Units: Why going unitless may not be a be a good answer for your projects

Example 4: Feet vs. US Survey Feet

This one is especially fun for people working in the United States.

And by fun, I mean:

“Why is everything shifted just enough to ruin my day?”

Feet and US Survey Feet are very close, in some locations.

So close that the difference sounds harmless.

It is not always harmless.

A Feet vs. US Survey Feet mismatch is not like Inches vs. Feet. It usually does not look twelve times wrong.

Instead, it often looks like a shift.

The drawing may look mostly correct, but the data is not sitting exactly where it should.

That makes the troubleshooting worse, because now everyone gets to argue whether it is:

• a coordinate system problem

• a surface problem

• an Xref problem

• a data shortcut problem

• a survey problem

• “maybe the base file moved”

• “maybe somebody exploded something”

• “maybe Civil 3D just does that”

No.

Sometimes one drawing is just wearing the wrong "foot".

The size and direction of the apparent shift depends on the project location, coordinate values, projection, origin, and workflow. On large-coordinate projects, a tiny unit difference can become very visible.

Which is great, because nothing says “efficient production” like a unit mismatch pretending to be a mystery.

Example 5: “But We Saw the Data Shortcut Shift”

Civil 3D data shortcuts are not Xrefs.

An Xref references another drawing file.

A data shortcut references Civil 3D objects, such as:

• surfaces

• alignments

• profiles

• corridors

• pipe networks

But here is the field observation that I have personally witnessed many times.

File	Coordinate System	Insertion Units
Base linework file	Same coordinate system	US Survey Feet
Civil 3D source/base file	Same coordinate system	US Survey Feet
Sheet file	Same coordinate system	Feet

The coordinate system matched in all files.

The base linework and Civil 3D source drawing were set to US Survey Feet.

The sheet was set to Feet.

When the Civil 3D data reference was created in the sheet, the referenced data appeared shifted.

The fix was:

1. Remove the data shortcut reference from the sheet.

2. Set the sheet insertion units to US Survey Feet.

3. Bring the data shortcut reference back into the sheet.

After that, the data aligned correctly.

INSUNITS is not documented as the direct scaling control for Civil 3D data shortcuts, but the host drawing’s unit environment can still matter when a data reference is created, especially in Feet vs. US Survey Feet projects.

In plain English:

The sheet is not just an empty bucket to dump things into and scales and units maintain from the sources files.

It has settings.

And if those settings disagree with the source files, things can get weird.

Because apparently the answer to:

“Does this setting really matter?”

is:

“Not directly, except when it absolutely ruins your set.”

Example 6: The Xref May Be Moving, the DREF May Be Moving, or Everyone Is Lying to You

In many plan sheets, users compare Civil 3D data references against Xref linework.

That means two different reference systems may be involved at the same time.

Reference Type	What Controls It
Xref/base linework	AutoCAD Xref and insertion-unit behavior
Civil 3D data reference	Civil 3D data shortcut behavior
Sheet drawing	Sheet drawing settings, including units

If the Xref and the data reference do not line up, do not immediately assume the data shortcut is wrong.

Also do not immediately assume the Xref is wrong.

Check both. Verify known x,y points in each base and the sheet.

A mismatched insertion-unit setup can affect the Xref directly.

And based on field testing, the sheet’s unit environment can matter when a data reference is created.

So verify:

Are all files using the same coordinate system and matching insertion units before references are attached or created?

Do not assume:

“The coordinate system matches, so units are fine.”

That sentence is how drawings become haunted.

Example 7: Manual Scaling Makes Everything Worse

The fastest way to turn a unit problem into a project problem is to manually move or scale the reference and pretend everything is fine.

An Xref comes in wrong.

Someone scales it manually.

The sheet looks right.

Everyone moves on.

Beautiful. Terrible. Very CAD.

Later:

• the Xref is detached and reattached

• a data shortcut is recreated

• a consultant background is updated

• the sheet is copied

• the template is reused

• someone checks coordinates

• someone asks why the surface is off

• someone says “it was fine yesterday”

The original problem was a unit mismatch.

The manual fix hid it.

Now the drawing has history.

And not the good kind.

Civil 3D’s “Set AutoCAD Variables to Match” Trap

Civil 3D has an option called:

Set AutoCAD variables to match

That sounds helpful.

And it can be.

But it can also change AutoCAD variables, including INSUNITS.

That means a user may think they are only working with Civil 3D drawing settings or coordinate systems, while AutoCAD insertion units are also being changed.

This does not mean Civil 3D drawing units and insertion units are the same.

It means the workflow can connect them.

Which is exactly why templates should be reviewed instead of spiritually trusted.

What to Check Before Blaming Civil 3D

Before scaling anything, moving anything, rebuilding surfaces, or accusing the surveyor, check the boring stuff.

The boring stuff is usually guilty.

Check	Why It Matters
Sheet INSUNITS	The host drawing’s insertion-unit setting
Source Civil 3D drawing INSUNITS	Should match the project’s intended unit basis
Base/Xref drawing INSUNITS	Xrefs are directly affected by insertion-unit scaling
INSUNITSDEFSOURCE	Used when source content is unitless
INSUNITSDEFTARGET	Used when the target drawing is unitless
Civil 3D drawing units	Separate from insertion units, but still important
Coordinate system / zone	Matching coordinate systems are necessary, but may not be enough
“Set AutoCAD variables to match”	Can change AutoCAD variables such as INSUNITS
Xref scale factor	Helps show whether an Xref was automatically or manually scaled
Existing data references	May need to be removed and recreated after unit correction
Display precision	Can hide or reveal differences, but is not insertion units

Practical Troubleshooting Workflow When Things Are Not Lining Up

1. Do not manually move or scale the data.

   That is how a unit problem becomes a project legend.

2. Check the sheet INSUNITS.

   Especially if the shift is small and the project uses large coordinates.

3. Check the source drawing INSUNITS.

   Confirm whether it is Feet, US Survey Feet, Unitless, or something else.

4. Check the base/Xref drawing INSUNITS.

   Xrefs are directly affected by insertion-unit scaling.

5. Check Civil 3D drawing units and coordinate system.

   Matching coordinate systems are necessary, but they may not be enough.

6. Check whether “Set AutoCAD variables to match” was used.

   It may have changed INSUNITS.

7. If the sheet units were wrong when the DREF was created, test removing and recreating the DREF.

   Do this after correcting the sheet’s insertion units.

8. Only after all of that should anyone consider manual correction.

   And even then, maybe go talk with someone in GIS before making the drawing worse with confidence.

   
   

Bottom Line

Insertion units are not Civil 3D drawing units.

Data shortcuts are not Xrefs.

Decimal precision is not insertion units.

Unfortunately, all of these things live close enough together in production workflows to ruin a perfectly good sheet set.

INSUNITS is documented as controlling automatic scaling for blocks, images, and Xrefs. Civil 3D data shortcuts are a separate reference system. But in Feet vs. US Survey Feet workflows, field testing shows that the sheet’s insertion-unit setting can still affect whether a newly created Civil 3D data reference aligns correctly.

So the rule is simple:

Match the insertion-unit environment before attaching Xrefs or creating data references.

Not after.

Not once the sheet is labeled.

Not after the PM asks why the existing ground is vacationing three feet northeast of where it should be.

Before.

Because sometimes the drawing is not haunted.

Sometimes the drawing just has the wrong foot.

Thanks for stopping by the Den! Civil 3D: It’s not a bug, it’s a feature. Allegedly.

Images provided by personal screen snips and Microsoft Copilot 2026.