Anonymous Blocks in AutoCAD – What They Are & How to Fix

Last updated July 27, 2026

Open someone else’s drawing, look at the block list, and there they are: *U27, *U28, *X4, dozens of them. You did not make them, you cannot edit them, and PURGE will not shift them.

They are anonymous blocks, and they are usually not a problem. Here is what they are, where they come from in a modern drawing, and what you can actually do about the ones that matter.

What they are

Autodesk’s current definition:

The block definitions (BLOCK) table in a drawing can contain anonymous blocks (also known as unnamed blocks), that AutoCAD creates to support dynamic blocks, tables, hatch patterns, and associative dimensions.

Note what is on that list. Hatches and dimensions have always made them. Dynamic blocks and tables are the modern additions, and dynamic blocks in particular are why a drawing today has so many more than one from twenty years ago.

The prefixes

You will also see *Model_Space and *Paper_Space in the block table. Those are reserved layout definitions, not anonymous blocks, and they are meant to be there.

A note on *A: this page used to list *A as anonymous groups. Unnamed groups are real and do get names of that shape, but they live in the group dictionary rather than the block definition table, so they are not anonymous blocks. No current Autodesk documentation lists *A as a block prefix, so it has been dropped from the table above.

The names are not stable

This one catches people out, and it invalidates a lot of advice you will find on forums:

Anonymous block names do not remain constant. Although a referenced anonymous block becomes permanent, the numeric portion of its name can change between drawing sessions.

So the *U105 you noted this afternoon may not be *U105 tomorrow. Anything you do about anonymous blocks has to match on the prefix, never on a number you wrote down earlier.

Why PURGE will not clear them

Because PURGE works on named objects, and these are unnamed by definition. They do not appear as tickable items in the Purge dialog, which lists “the named objects that are not used in the current drawing and that are purgeable”. Autodesk also states plainly that PURGE “will not remove unnamed objects from blocks or locked layers”.

The actual mechanism is automatic, and it is documented:

Unreferenced anonymous blocks are purged from the BLOCK definition table when a drawing is opened. Referenced anonymous blocks (those that have been inserted) are not purged.

Which gives you the whole answer in two lines. If an anonymous block is unused, closing and reopening the drawing clears it — you do not need to do anything. And if one refuses to go away, that is not a fault: something in the drawing is still using it. A hatch, a dimension, a table, or a dynamic block.

Chasing them is usually wasted effort. They are how AutoCAD stores things you asked for.

Dynamic blocks: the modern culprit

This page originally dated from AutoCAD 2004, which is before dynamic blocks existed. They are now the main reason a block list fills up.

A dynamic block reference that has been changed from its default state — stretched, flipped, swapped to another visibility state — has to be stored somehow, and that variant lives in the block table under an anonymous name. Insert one door block and drag it to five different widths, and you have not made five blocks; you have made one dynamic block with several anonymous variants behind it.

Worth knowing that Autodesk documents this connection only in the developer material — the AutoLISP and ActiveX guides. The user-facing dynamic block help does not mention it, which is exactly why so many drafters find the block list baffling.

If you want a reference back to its default state, that is RESETBLOCK, which “resets one or more dynamic block references to the default values of the block definition”. Reset the references that do not need to be different and the variants they relied on become unreferenced — and then the automatic clean-up above takes care of them next time the drawing opens.

Exploding them

Uniformly scaled *U blocks explode normally. The awkward case is the non-uniformly scaled one, and Autodesk’s wording here has not changed in twenty years:

When nonuniformly scaled blocks contain objects that cannot be exploded, they are collected into an anonymous block (named with a “*E” prefix) and referenced with the nonuniform scaling. If all the objects in such a block cannot be exploded, the selected block reference will not be exploded. Body, 3D Solid, and Region entities in a nonuniformly scaled block cannot be exploded.

That is where *E blocks come from: an explode that only partly succeeded. The leftovers get parked in an anonymous block rather than lost.

Turning one into a normal block

Correction to the older version of this page: it used to start this procedure with “RENAME *U105 to U105”. That does not work. Autodesk’s own support article on the subject is titled around the problem — how to rename anonymous blocks “where the RENAME command is not applicable” — and confirms the functionality is not directly implemented. The RENAME command will not offer you an anonymous block.

The simple route, and it works on LT. Autodesk documents a procedure that needs no LISP, no Express Tools and no API at all. Their steps, for a block that cannot be edited because it is anonymous:

1. Select the block.
2. Explode the block.
3. Purge the block.
4. Create a new block with a specific name.

You lose the anonymous definition and rebuild it as a proper named block, which is usually exactly what you wanted. The symptom Autodesk describes alongside it is worth recognising: the block is selectable on screen, but its name is nowhere in the Block Editor list.

Two cautions. Exploding is destructive — if the block is a dynamic block variant you will lose the dynamic behaviour, so check what you are exploding first. And if the geometry is non-uniformly scaled, re-read the explode section above before you start.

The other route is going at the block table through the API rather than the command line, which suits doing several at once. Autodesk’s article describes the approach: walk the block definitions, match names against the prefix with a wildcard — note that the asterisk has to be escaped, since it is itself a wildcard character — and set a new name on the block object directly.

Once a block has a real name, ordinary tools work on it again. In full AutoCAD you can then use BLOCKREPLACE, which “replaces all instances of a specified block with a different block”, and follow it with PURGE — the BLOCKREPLACE documentation notes you can then “use the PURGE command to remove the unreferenced block definition from the drawing”.

Do this carefully, and not in bulk. A *U block may be a dynamic block variant that something in the drawing depends on. Renaming those wholesale is a good way to break blocks that were working perfectly well. Work on the one you actually need, on a copy of the drawing, and check the result before you go near the issued set.

If you are on AutoCAD LT

BLOCKREPLACE is an Express Tool, and Express Tools are not in LT. Autodesk is explicit: they “are not supported by AutoCAD LT and are not included with the application”.

Worth stating clearly because it is a common misconception: LT gained AutoLISP in the 2024 release, but that did not bring Express Tools with it. They are two separate things. So an LT user cannot use BLOCKREPLACE — but the explode, purge and re-block procedure above needs none of it and works fine on LT. A LISP routine against the block table is also available, since LT does have AutoLISP. Any routine you use on LT also has to avoid the acet- Express Tools functions, which Autodesk lists as “AutoCAD for Windows only; not available in AutoCAD LT for Windows, or on Mac OS and Web”.

The routine

Unanon.lsp — converts anonymous blocks with a *U prefix to normal AutoCAD blocks. Free download, and it has been on this site a long time. Read the caution above before running it on anything that matters.

More routines in the free AutoLISP library, and if you want them to load themselves every session, see building a CAD LISP library.

The short version

• Anonymous blocks support dynamic blocks, tables, hatches and associative dimensions. They are normal.
• The numeric part of the name changes between sessions — never act on a remembered number.
• PURGE does not touch them. Unreferenced ones clear themselves when the drawing next opens.
• One that will not go away is still being used by something.
• RENAME does not work on them. The documented fix is explode, purge, then re-block with a real name.
• BLOCKREPLACE is an Express Tool, so it is not available on LT.

References

1. About Anonymous Blocks (AutoLISP) — Autodesk AutoCAD 2026 AutoLISP Developer’s Guide. The definition, the *Unnn form, the *Tnnn / *Dnnn / *Xnnn prefixes, the automatic purge at drawing open, and the unstable numeric portion of the name.
2. EXPLODE (Command) — Autodesk AutoCAD 2026 Help. The *E prefix and the non-uniform scaling behaviour.
3. How to rename anonymous blocks in AutoCAD Products — Autodesk Support, 2 June 2026. That RENAME is not applicable, and the LISP approach.
4. Cannot Edit Blocks in a specific AutoCAD-based drawing — Autodesk Support, 19 June 2024. The explode, purge and re-block procedure, and the Block Editor symptom.
5. RESETBLOCK (Command) — Autodesk AutoCAD 2026 Help.
6. BLOCKREPLACE (Express Tool) — Autodesk AutoCAD 2026 Help.
7. Purge Dialog Box — Autodesk AutoCAD 2026 Help. Named items only; unnamed objects are not removed.
8. Are Express Tools available in AutoCAD LT? — Autodesk Support, 2 September 2025.
9. BLOCK (DXF) — Autodesk AutoCAD 2026 DXF Reference. Group code 70, flag 1: an anonymous block generated by hatching, associative dimensioning, other internal operations, or an application.