conflict: unable to delete ... (must be forced) - container ... is using its referenced image means a container, usually a stopped one you forgot, was created from that image. Remove the container with docker rm, then docker rmi works.

Find the container with docker ps -a --filter ancestor=<image>; plain docker ps hides stopped containers, which is why the message is surprising. Forcing it with docker rmi -f only removes the name: in the test the image stayed on disk as an untagged <none> image.

The error

PS> docker rmi fix8-cli-img:2
Error response from daemon: conflict: unable to delete fix8-cli-img:2 (must be forced) - container 5d6f005f77e5 is using its referenced image 2a54e098cd3b

Removing the same image by its ID gives a second wording of the same refusal:

PS> docker rmi 2a54e098cd3b
Error response from daemon: conflict: unable to delete 2a54e098cd3b (must be forced) - image is being used by stopped container 5d6f005f77e5

Why it happens

Every container keeps a reference to the image it was created from, because its filesystem is a thin layer on top of that image's layers. A container that has exited still exists until you remove it, so the image is still in use. The engine refuses to delete the last name of an image that a container depends on.

If the image has a second tag, docker rmi on one tag does not fail: it only prints Untagged, because the image itself stays. The conflict appears on the last tag or on the image ID. Containers started with docker run without --rm pile up this way.

The fix

PS> docker ps -a --filter ancestor=fix8-cli-img:2 --format '{{.Names}}  {{.Status}}'
fix8-cli-h  Exited (0) 4 seconds ago
PS> docker rm fix8-cli-h
fix8-cli-h
PS> docker rmi fix8-cli-img:2
Untagged: fix8-cli-img:2
Deleted: sha256:2a54e098cd3b6d51e58527e54c5200614e5cd9414179e85c7754a66763795174

Once the container is gone the image is deleted, not only untagged. If the container still holds data you need, copy it out with docker cp first. For throwaway runs, add --rm to docker run so the container is removed when it exits and never blocks an image again.

docker rmi -f is not a shortcut. On a second test image it printed only Untagged: fix8-cli-img:4; the stopped container stayed, now listing the bare image ID 74aba1a7a224 as its image, and that ID appeared under docker images --filter dangling=true as <none>:<none>. It was still there after the container was removed, and needed a separate docker rmi 74aba1a7a224 to go.

How it was reproduced

Docker Desktop on Windows 11, client and engine 29.9.2, Windows PowerShell 5.1. A test image fix8-cli-img:2 was made with docker commit from an alpine:latest container, given a second tag, and used by one docker run without --rm. Removing the second tag only untagged it; removing the last tag and then the ID gave the two messages above. After docker rm of the container, docker rmi deleted the image. The names in the output are the test's own.

Frequently asked

How do I find which container is using a Docker image?
Run docker ps -a --filter ancestor=<image name or ID>. The -a flag matters: stopped containers still hold the image and plain docker ps does not list them.
Is it safe to use docker rmi -f?
In this test it removed only the name. The stopped container stayed, and the image stayed as an untagged none image even after the container was removed, until docker rmi with its ID deleted it. Removing the container first is cleaner.
Why does docker rmi only print Untagged and not delete the image?
The image has another tag or is referenced by another name. Docker removes only the name you gave; the image is deleted when its last tag goes and no container uses it.

More decoded errors in the Fixes category. A volume that will not go away has the same cause and fix, covered in volume is in use.