Paste the output of docker history --no-trunc <image> to see which layers are actually bloating your image, sorted largest first. Nothing is ever uploaded.
Layers, largest first
How it works
The parser accepts either the custom tab-separated format from --format "{{.CreatedBy}}\t{{.Size}}" or the default table output, locating the size on each line with a strict regex that must match a whole token (a number directly followed by B, KB, MB, GB, or TB) so it doesn't mistake part of a hex image ID for a size — then it sorts every layer largest-first and scales the bars against the biggest one.
FAQ
Why do I need --no-trunc when generating the docker history output?
The default docker history output truncates the CREATED BY command to a fixed width with an ellipsis, which makes it hard to tell which command actually produced a large layer. Running docker history --no-trunc keeps the full command visible so the analyzer's bar labels are actually useful.
Why does the parser require a strict size token instead of just searching for KB or MB anywhere in the line?
A loose substring search could match something like "1b" inside a hex image ID such as a1b2c3d4e5f6 as if it were a "1B" size value. The parser only accepts a token that's entirely a number immediately followed by a unit (B, KB, MB, GB, or TB), which avoids that false match.
Free, unlimited, no account. If this saved you a paid tool, a small thanks is appreciated.