I make Overlay the default for Xrefs. If someone on my team uses Attach, I want to hear the reason, and “it was the default” doesn’t count.
In December 2025 IMAGINiT published a Civil 3D best practices post that says “Always use ATTACH, never OVERLAY, unless isolating short-term references.” That’s the opposite of how I run Xrefs, and the opposite of what I’ve written here before, so here’s my case for the other side.
What actually changes between the two
Both options display the referenced drawing in your current drawing. The difference shows up when another drawing references yours.
If A attaches B, and a sheet references A, B comes along as a nested reference. Then whatever B attached. And so on down the chain.
If A overlays B, B displays in A but doesn’t travel through A into the sheet. If the sheet needs B, the sheet references B itself.
Overlay controls what travels downstream from your drawing. It doesn’t strip out references the other drawing attached on its own. If B attached C, C still shows up in A.
That’s the whole mechanical difference. Everything else in this post follows from it. If you want the full list of what an attached Xref drags along, nested references, images, point clouds and Civil 3D objects included, I covered that in What Else Comes Along for the Ride When You Attach an Xref?
The chains nobody planned
Here’s how it goes. Survey attaches the existing topo into a base. Someone attaches that base into the grading file. Someone else attaches the grading file into the utility plan. Now the plan sheet loads four levels of files, and the person who built the sheet only asked for one.
You pay for that in a few ways:
- Every drawing carries the weight of everything nested under it, whether it needs it or not.
- Move one deeply nested file and the broken-path errors show up in drawings you never opened.
- Two people attach each other’s files “for context” and you’ve built a loop.
That last one is worth slowing down on. Autodesk’s documentation describes a circular reference with attaches: A attaches B, B attaches C, C attaches A. AutoCAD detects it, warns you, and breaks the loop for that session when it loads. Breaking the loop during loading doesn’t repair the saved reference relationships. Those still need to be corrected in the source drawings.
Overlay can still sit in a loop. Two linework files overlaying each other is a loop. But an Overlay doesn’t pass that loop on to every sheet that references either file. The underlying relationships still need to be traced and corrected.
Chains and loops are the two patterns I wrote about in The Two Ways a Civil 3D Project Eats Itself. Unplanned attaches feed both of them.
The Civil 3D curveball
In plain AutoCAD, that’s close to the whole story. Civil 3D adds a second reference system the External References palette doesn’t show: data shortcuts. If you need the refresher on how the two differ, start with Understanding Civil 3D Data Shortcuts vs Xrefs.
Your grading file consumes the existing ground surface from the survey file through a Dref. That’s a dependency, even though the Xref palette won’t list it. Now someone overlays the grading file back into the survey drawing for context. As an Xref Overlay, it won’t nest into drawings that reference the survey file. In Civil 3D the dependencies now run both ways. Grading consumes survey data, and survey references grading for display. That’s a loop, and it runs through Civil 3D objects.
So Overlay is not a free pass in Civil 3D. It stops downstream nesting, but switching between Attach and Overlay won’t remove that two-way dependency. Before you overlay a drawing into one that publishes data, check what the file you’re grabbing already consumes. If it consumes from you, that innocent Overlay just closed a loop. I walked through this one for AutoCAD veterans in The Xref Habit That Follows You Into Civil 3D, and the Curveball Waiting There.
Where I think IMAGINiT’s advice goes wrong
Their reasoning is that Attach makes referenced data propagate to your sheets. That’s true. It’s also the problem when nobody meant for it to happen.
I want each sheet to Xref the bases it needs, directly. That keeps the sheet’s drawing references in plain view and easy to manage. Yes, the External References palette has a tree view that shows nested Xrefs. But changing any of those relationships means going back into the drawing that owns them, and data shortcuts need a separate check either way.
Propagation saves you a few clicks when you build the sheet. You pay it back every time a path breaks, a file moves, or someone closes a loop.
Attach is the right call when propagation is intentional. That doesn’t make it a good default for every reference.
I’m not alone on this. The Wisconsin Department of Transportation’s Civil 3D knowledge base has a tool that loads an Xref onto its own layer, and it creates that Xref as an Overlay with a relative path. That’s one state DOT building Overlay into its production tooling.
And to be fair to the IMAGINiT post, the rest of their Xref advice is solid. Relative paths, purge your source drawings before you reference them, keep Dref source files light. I’d hand that list to a new user. I just disagree with the first line.
When I still use Attach
Attach earns its place when the nested content is part of what you’re delivering. A controlled composite base is the example I see most. Its consumers need the component drawings to come along, so you attach them on purpose.
That only works with a clear owner, a documented reference structure, and everyone agreeing on what consumers will inherit.
My test is one question. Does this content need to travel with the host drawing? If yes, Attach may be right. If it’s working context, it’s an Overlay.
The rule I give my team
Use Overlay for context. Use Attach when nested content has to travel with the host. In Civil 3D, check data dependencies before you reference a downstream drawing back into its source.
If you’ve got drawings full of attaches today, check before you flip them. Some of those attaches may be feeding sheets on purpose. Find which sheets and composite drawings rely on the nested content. Test on copies, reopen the downstream drawings, and compare the plots. Where something you needed disappears, reference it directly or leave that attach alone.
Then the switch is quick. In the External References palette, double-click the Type column to toggle between Attach and Overlay, or select several and change them all at once. You can’t change the type of a nested Xref from the host, so fix it in the file that owns it.
To find which files are involved, don’t guess. If you run Autodesk Desktop Connector, Reference Explorer maps drawing dependencies and flags circular and missing references. Check both the Xref relationships and the Civil 3D data relationships.
Cheers,
Shaan
