Repository navigation
The new `docker images' output format is pretty unusable #6650
Description
Description
First of all: there's lots of legacy code relying on the old output. Hence changing this in such a way really a bad idea - even though having told pretty much everybody that for parsable output --format should be used. There real old code out there.
But even worse: the new output format truncates image names so that grepping for image names always requires --no-trunc which is really inconvenient.
Reproduce
docker images
Output: lots of truncated image names that aren't readable.
Expected behavior
docker images should default to output that is useful for most cases.
docker version
Client: Docker Engine - Community
Version: 29.0.0
API version: 1.52
Go version: go1.25.4
Git commit: 3d4129b
Built: Mon Nov 10 21:49:15 2025
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 29.0.0
API version: 1.52 (minimum version 1.44)
Go version: go1.25.4
Git commit: d105562
Built: Mon Nov 10 21:45:58 2025
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v2.1.5
GitCommit: fcd43222d6b07379a4be9786bda52438f0dd16a1
runc:
Version: 1.3.3
GitCommit: v1.3.3-0-gd842d771
docker-init:
Version: 0.19.0
GitCommit: de40ad0docker info
Client: Docker Engine - Community
Version: 29.0.0
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.29.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.40.3
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 3
Running: 0
Paused: 0
Stopped: 3
Images: 274
Server Version: 29.0.0
Storage Driver: overlay2
Backing Filesystem: btrfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: fcd43222d6b07379a4be9786bda52438f0dd16a1
runc version: v1.3.3-0-gd842d771
init version: de40ad0
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.17.7-300.fc43.x86_64
Operating System: Fedora Linux 43 (Workstation Edition)
OSType: linux
Architecture: x86_64
CPUs: 32
Total Memory: 125.4GiB
Name: ...
ID: 8609766b-6859-4c6d-b799-973d7216c328
Docker Root Dir: /var/lib/docker
Debug Mode: false
Username: mdietze
Experimental: false
Insecure Registries:
...
::1/128
127.0.0.0/8
Registry Mirrors:
https://mirror.gcr.io/
Live Restore Enabled: false
Firewall Backend: iptables+firewalldAdditional Info
No response
Activity
jarbelix commentedon Nov 13, 2025
See this #6651
vvoland commentedon Nov 13, 2025
Thanks for reporting!
In the default case the names are truncated to fit the terminal, but when the stdout is redirected to a non-terminal the width can't be determined and falls back to 80.
I've opened a PR to disable the name truncation when the output is redirected: #6656
jaykae commentedon Nov 13, 2025
I would also add that regardless of the intent, disabling grep for quick checks is a poor experience. The image is on my machine when I run
docker image lsBut when I try to grep I get told write a much longer command.docker version
vvoland commentedon Nov 13, 2025
@jaykae this is fixed with: #6656
We'll be releasing 29.0.1 soon that will include this fix.
mbert commentedon Nov 14, 2025
Thank you, that will help. Still one more remark / suggestion. While I think that this change should never had been made (because there is lots of legacy code relying on the old output, and this will break it), I think the idea of truncating long image names at the end rather questionable, because the end is what you are normally most interested to see.
If an image name is too long this is most likely caused by a long prefix / server part. Hence if image names get too long I'd like to propose removing characters and adding an ellipsis ("...") near the beginning in such cases, say, after the 5th position or so. In that case the actual image name and tag will still remain readable in most cases.
cruizba commentedon Nov 15, 2025
+1 @mbert , I am not sure if changing the format of
docker imageswas a good idea. I'm pretty sure a lot of scripts use that output and will breakag-TJNII commentedon Nov 21, 2025
Agree, this is a pretty impacting change. I also see it's buggy, with the ability to pin the format desired being unstable (#6663). Apparently it also hides images that were previously shown unless passed a flag, which is super bad in my opinion. I'm not sure the intent of these changes, but from a user perspective it's changing things in breaking ways that have been stable for years.
Be very careful with this kind of change. I view this like rearranging the controls on a car, or rearranging someone's bathroom in the middle of the night. It's annoying at best, and definitely unwelcome when waking up in the middle of night and realizing slightly too late that the toilet isn't where it was yesterday. Changes to the user interface are highly visible, and probably not welcomed by a significant set of users. Please be deliberate in what's changed, advertise it well, and test it very thoroughly. My $0.02 as a long-time user.
vvoland commentedon Nov 24, 2025
Thank you, we highly value your input!
I can see why the name truncation is indeed a bad UX and I've opened a PR to remove it: #6675
I hope this makes it now possible to keep compatibility with the output while still experiencing the new view.
Long-term we want to make some UX changes to the overall CLI experience - this is especially important with the transition to the containerd image store which brings proper multi-platform support and enables us to work on further improvements of the Engine.
Of course it's still important for us to not break existing users and keep the CLI as backwards compatible as we can.
Most CLI operations have the
--formatoption that allows you to be explicit about that (and also makes the parsing easier for you!).4 remaining items
nmarley commentedon Dec 5, 2025
I agree, CREATED was super useful for me too. CONTENT SIZE and EXTRA however, are not.
Not sure why the default was changed instead of using
--formatfor the new output if that's what Docker wants to transition to.gasparetto commentedon Dec 22, 2025
I’m adding a comment to save a few minutes for anyone who might need it. It’s possible to obtain the same output format as the old version by using this command:
docker image ls -a --format "table {{.Repository}}\t{{.Tag}}\t{{.ID}}\t{{.CreatedSince}}\t{{.Size}}"mirao commentedon Dec 22, 2025
@gasparetto Also
docker images --no-truncworks for me well - to get a list of images by the "created" date descending.numbworks commentedon Jan 19, 2026
@gasparetto
Thank you for sharing! The new output is awful!
adudek16 commentedon Jan 21, 2026
This is impacting me as well. Changing the default output without calling it out in release notes (I may have missed) isn't ideal.
TomK32 commentedon Jan 22, 2026
I agree on the CREATED column being chopped and the whole list being sorted by the image name instead of creation date is a massive change that needs a proper fix beyond just point to the
--formatoption.Am I mistaken or do we have different kind of users? People who build images prefer their image list being sorted by creation date while the end user will be happy with the alphabetical order.
How about bringing arguments that feel a lot like linux'
lsto avoid the length--formatargument? I can live withdocker images -tquite happily as long as it shows me the last images I created at the bottom of the output.-l / --long(some truncation as default makes sense for those pushing images to their own repos, the longest image name I have right now is 101 characters long)-t / --time-s / --size-r / --reverseplaurin84 commentedon Jan 27, 2026
While the EXTRA column is nice, the removal of the other colums is a major change that will break a lot of automation for a lot of people.
I'm not sure what is the narrative for this change, but hiding important columns in an additional argument like --no-trunc will not simplify anyone's workflow. It might look simple and sensible on paper, but it adds complexity to the usability and learning curve for users.
I understand columns are customizable, and this is good. However, the default columns from "docker images" should keep showing the tags independently from the name imho.
danielhoherd commentedon Feb 5, 2026
FYI
docker images --format=tableshows the exactdocker<29.0.0style output. Thedocker images --helptext in version 29.2.1 (and probably others) even erroneously lists this as the default output.IMHO it would've been better to put this new style of output through a transition phase where it was introduced as
--format=whatever-the-new-thing-isas a non-default option with a warning on stderr to users that the default option is being changed from--format=tableto--format=whatever-the-new-thing-isin version 30.0.0.Leaving the default as it was would've been best though IMHO.
pfuntner commentedon Feb 11, 2026
I recently upgraded my Docker package and was hating the new format too. I added:
to my
~/.docker/config.jsonanddocker imagesdisplayed with the old format. I already had several a list of servers underauthsand I am hopingimagesFormatwill persist if theauthsgets changed.jeffrson commentedon Feb 24, 2026
BTW, the new
docker imagesseems to need-ain order to show tagged and untagged images likeafter
docker pull image. This is also unexpected. AFAICT, "untagged" is neither "intermediate" nor "dangling".So you can configure the behaviour through config.json and/or command line. But it needs to be done on every system for every user. Not nice.
Daryes commentedon Apr 16, 2026
Any news on this ?
The v29 implementation of docker images is a major regression : there is not real major change in docker to warrant this, and the only welcomed addition is the extra column,
Furthermost, hiding images in the default view with a name but missing a tag is extremely impactful.
Also, having the image names colored with a dark blue is not very readable over a black window.
And before anyone have the bright idea to suggest using the client configuration, it is only usable on a per-user basis : there is no global configuration usable out of the box on any server.
Btw, I would like to remind to people that docker cli is not used only on a personal computer at home. Such a change is unprofessional, at best.
What's need to be done :
Then, we can talk about changing the default output.
Jwalker107 commentedon Apr 29, 2026
Thank you, this comment helped me immensely.
For the search box, this issue affected me with MEND / WhiteSource scans. After running an 'Image Discovery' (which likely was just
docker imagescommand), MEND incorrectly parsed the output due to the new column order, and attempted to mount the 'DISK USAGE' instead of the 'IMAGE ID', as these two columns are swapped.Updating the ~/.docker/config.json with
"imagesFormat":"table":resolved the issue for me as well.Daryes commentedon Jun 10, 2026
As a reminder, and unless the option exists but undocumented, I will remind that the imagesFormat" parameter does not allow to fix the issue in a professional environment where fleets of servers are used : the parameter is at the user level only.
There is no equivalent that can be placed under /etc/docker/ affecting all users, both newly created and already existing.
So the point of the enshitification of the
docker image lscommand still stands._prepublish_updates: record ch4-6 minimize-version-changes policy
PeterDaveHello commentedon Aug 8, 2026
Thank you for the work on improving multi-platform image visibility. The new tree view is a useful addition, especially as Docker moves toward the containerd image store.
One concern with making it the default is that it changes a long-established CLI interface without a transition period. The removal of the
CREATEDcolumn, together with the new layout and sorting, makes it harder to assess image freshness at a glance and has affected existing scripts and workflows.While
--formatoffers a workaround, it shifts the compatibility burden to individual users and systems. Would it be possible to keep the legacy table as the default and make the tree view opt-in? This would retain the benefits of the new view while preserving a predictable experience for existing users.