Why some downloaded blocks come in wrong color despite ByLayer

Why this feels like a contradiction

You check the block's Properties, color reads ByLayer, exactly as it should, and yet it stubbornly displays in a color that has nothing to do with the layer it's sitting on. This trips people up because ByLayer feels like it should be the end of the story, the object inherits the layer's color, full stop, but ByLayer only describes the color of the specific entity you're looking at in Properties, and a block reference is a container, what you're actually seeing rendered on screen is a combination of everything nested inside it, some of which may not be set to ByLayer at all even though the outer block reference itself is.

The most common cause: hardcoded color on entities inside the block

The block reference itself showing ByLayer only tells you about the block insertion point's own color property, it says nothing about the individual lines, arcs, and hatches that were used to build that block's definition in the first place. If whoever originally drew the block assigned a specific hardcoded color, say red, to one particular line while building it, rather than leaving that line set to ByLayer too, that hardcoded red will display regardless of what layer you insert the finished block onto or what the outer block reference's own color property says. This is by far the most common cause of a block that visually contradicts its own ByLayer setting, and it's baked into how the block was authored, not something you did wrong on insertion.

How to actually find the hardcoded entity

Open the Block Editor by double-clicking the block, or typing BEDIT and selecting it from the list, and once inside, select each piece of geometry individually and check its color property in the Properties palette. Anything that shows a specific named or numbered color rather than ByLayer or ByBlock is the culprit, and you can select it and change its color property to ByLayer directly inside the Block Editor, save the block definition, and every instance of that block throughout your drawing updates correctly at once, which is much faster than trying to fix each inserted copy individually.

ByBlock is a different setting that behaves differently again

It's worth understanding the third option here too, since it's easy to conflate with ByLayer, ByBlock color means the entity takes on whatever color the block reference itself is set to when inserted, rather than the layer's color. This is actually the more flexible authoring choice for anyone building blocks meant to be reused across drawings with different color standards, since you can insert the exact same block definition and give different instances different colors just by changing each instance's own color property, without touching the underlying definition at all. If a block was built with internal geometry set to ByBlock rather than ByLayer, and you're seeing inconsistent colors across different instances of what should be the same block, checking whether the instances themselves have different color overrides set on the block reference, rather than the layer, is the right diagnostic direction.

Nested sub-blocks add another layer to check

If the block you're troubleshooting contains nested sub-blocks, remember that each nested block has its own independent color chain to check too, a parent block set correctly to ByLayer with a sub-block inside it that itself contains a hardcoded color on one of its entities will still show that wrong color, because the color override is happening two levels down from where you're looking. Double-click into nested sub-blocks one level at a time within the Block Editor if the first pass through the top-level geometry didn't reveal an obvious hardcoded color, the culprit is very often sitting one level deeper than where you started looking.

A layer-level cause worth ruling out, and why ByLayer authoring matters

Separately from anything inside the block itself, double check the layer's own assigned color hasn't been overridden at the object level somewhere else in your drawing, and confirm you're checking the right layer, it's a common slip to assume a block landed on the layer you intended when it actually inherited whatever layer happened to be current at the moment you inserted it.

This whole class of problem is exactly why the recommended, professional way to construct a block is to draw every piece of its geometry on layer 0 with color, linetype, and lineweight all set to ByLayer, never hardcoded, so the finished block behaves predictably no matter which layer it eventually gets inserted onto. A block authored that way always takes on the color of whatever layer is current at insertion, cleanly and consistently. If you build your own blocks from scratch rather than only using downloaded ones, carrying this habit forward saves the next person who inserts your block, possibly yourself six months later, exactly this kind of color troubleshooting.

Fixing it fast when you're on a deadline

If you don't have time to dig into the Block Editor mid-deadline and just need the color right for one instance right now, selecting the inserted block and applying a color override directly through Properties will visually force it to the color you want for that instance, it's not the clean long-term fix since the underlying block definition still carries the hardcoded color issue, but it gets you an accurate-looking drawing immediately, and you can go back and properly correct the block definition in the Block Editor once the deadline pressure eases.

Viewport-specific layer property overrides are worth checking too if you're troubleshooting this specifically in a layout tab rather than model space, AutoCAD lets you assign a different color to a layer inside one particular paper space viewport without changing that layer's color anywhere else in the drawing, which is a legitimate and fairly common technique for making the same layer read differently across different sheet layouts. If a block looks correct in Model space but wrong specifically inside one layout's viewport, open the Layer Properties Manager while that viewport is active and check the VP Color column specifically, rather than the regular Color column, for an override sitting there.

Saved layer states are another source worth ruling out on a drawing that uses them heavily, if someone saved a layer state at some point with a manual color override baked in for a specific layer, restoring that saved state later can silently reapply the override even though nothing about the block or the base layer definition itself has changed since. Checking the Layer States Manager for any states that might have been restored recently, and comparing their captured layer properties against your current ones, catches this less common but genuinely confusing cause before you spend too long searching inside the block definition for something that isn't actually there.